From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 5F2853858C52 for ; Fri, 3 Feb 2023 09:40:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5F2853858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=suse.cz Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 211C421024; Fri, 3 Feb 2023 09:40:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1675417229; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cy2ao4eY/Qaj4MnuAgXtqnjU3pfhZiyR1v2NSuqp9ZY=; b=cS1UkNtP/nwlGi0uifahK+3EHtqYCJKAMBtxZwS9dI4gHyqJb/GeeDqPGrzG/5Bk8cx4o6 1z/vsbKWY0AKbtvS9LcH7NfSPkMj9MCD68lCXuM2IcZpDc3x8tw6wPxtZr41q+W2zgzsxB LssUI6F5+wC+YNY9xxu0XsB+jCS5oDc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1675417229; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cy2ao4eY/Qaj4MnuAgXtqnjU3pfhZiyR1v2NSuqp9ZY=; b=eV2wkHim1qgVdc4xhE5TY4uqxV2rG7gWef1J6RgTOgIGGiUMG6B0f8XwaKGKozJbxJx0Gw lwppipStQPQxSJCg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 12E891346D; Fri, 3 Feb 2023 09:40:29 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 5lybBI3W3GPpHAAAMHmgww (envelope-from ); Fri, 03 Feb 2023 09:40:29 +0000 From: Martin Jambor To: Richard Biener Cc: GCC Patches , Jan Hubicka Subject: Re: [PATCH] ipa: Avoid invalid gimple when IPA-CP and IPA-SRA disagree on types (108384) In-Reply-To: References: User-Agent: Notmuch/0.37 (https://notmuchmail.org) Emacs/28.2 (x86_64-suse-linux-gnu) Date: Fri, 03 Feb 2023 10:40:28 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_SOFTFAIL,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Feb 03 2023, Richard Biener wrote: > On Thu, Feb 2, 2023 at 5:20 PM Martin Jambor wrote: >> >> Hi, >> >> when the compiled program contains type mismatches between callers and >> callees when it comes to a parameter, IPA-CP can try to propagate one >> constant from callers while IPA-SRA may try to split a parameter >> expecting a value of a different size on the same offset. This then >> currently leads to creation of a VIEW_CONVERT_EXPR with mismatching >> type sizes of LHS and RHS which is correctly flagged by the GIMPLE >> verifier as invalid. >> >> It seems that the best course of action is to try and avoid the >> situation altogether and so this patch adds a check to IPA-SRA that >> peeks into the result of IPA-CP and when it sees a value on the same >> offset but with a mismatching size, it just decides to leave that >> particular parameter be. >> >> Bootstrapped and tested on x86_64-linux, OK for master? > > OK. I suppose there are guards elsewhere that never lets a > non-UHWI size type (like variable size or poly-int-size) through > any of the SRA or CP lattices? SRA tracks its accesses in simple integers so yes for that part. As far IPA-CP is concerned... all the values tracked conform to is_gimple_ip_invariant, so are either ADDR_EXPRs of a global variable or is_gimple_constant's. So its size should never be variable and I hope also never a complex poly-int. If you think it would be better, I can of course add the check. Thanks, Martin >> gcc/ChangeLog: >> >> 2023-02-02 Martin Jambor >> >> PR ipa/108384 >> * ipa-sra.cc (push_param_adjustments_for_index): Remove a size check >> when comparing to an IPA-CP value. >> (dump_list_of_param_indices): New function. >> (adjust_parameter_descriptions): Check for mismatching IPA-CP values. >> Dump removed candidates using dump_list_of_param_indices. >> * ipa-param-manipulation.cc >> (ipa_param_body_adjustments::modify_expression): Add assert checking >> sizes of a VIEW_CONVERT_EXPR will match. >> (ipa_param_body_adjustments::modify_assignment): Likewise. >> >> gcc/testsuite/ChangeLog: >> >> 2023-02-02 Martin Jambor >> >> PR ipa/108384 >> * gcc.dg/ipa/pr108384.c: New test. >> ---