From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 61DD33858D33 for ; Fri, 31 Mar 2023 09:18:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 61DD33858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass 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-out1.suse.de (Postfix) with ESMTPS id 8B28921B28; Fri, 31 Mar 2023 09:18:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1680254289; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZRig2pmKWDd5D8L4lyf1MfkVZIqIOxB3MSxBfti/+wg=; b=3b3TohrHY3HCPaKPI37xYEIiwBKZMFYs7RfJmnZhhi/tQ9NCKOrmaGO/pjuTe7e8eUhkqz WQn6HszJkLt/36/91CAxPGjK5BzzGLWxd1VARpHxrEpGH9xCiqCAlWs3Au71d35hTzaDjD xjublrh69gf26xO8BTJf65Gx9zB/ozM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1680254289; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZRig2pmKWDd5D8L4lyf1MfkVZIqIOxB3MSxBfti/+wg=; b=LEPzOo8bCLzC7lpfilDOR5XLvg+SzGxwpj6QqegrDa2uq1mtmG1QcLaz2ZqagqOjWPDxmb tsoP3xykTGjcqbBQ== 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 7F566133B6; Fri, 31 Mar 2023 09:18:09 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id x1wKH1GlJmTfOAAAMHmgww (envelope-from ); Fri, 31 Mar 2023 09:18:09 +0000 From: Martin Jambor To: Richard Biener Cc: GCC Patches , Jan Hubicka Subject: Re: [PATCH] ipa: Avoid constructing aggregate jump functions with huge offsets (PR 109303) In-Reply-To: References: User-Agent: Notmuch/0.37 (https://notmuchmail.org) Emacs/28.2 (x86_64-suse-linux-gnu) Date: Fri, 31 Mar 2023 11:18:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, On Fri, Mar 31 2023, Richard Biener wrote: > On Fri, Mar 31, 2023 at 10:46=E2=80=AFAM Martin Jambor = wrote: >> >> Hi, >> >> we are in the process of changing data structures holding information >> about constants passed by reference and in aggregates to use unsigned >> int offsets rather than HOST_WIDE_INT (which was selected simply >> because that is what fell out of get_ref_base_and_extent at that time) >> in order to conserve memory, especially at WPA time. >> >> PR 109303 testcase discovers that we do not properly check that we >> only create jump functions with offsets (plus sizes) that fit into the >> smaller type. This patch adds the necessary check. >> >> Bootstrapped and tested on x86_64-linux. OK for master? >> >> Thanks, >> >> Martin >> >> >> gcc/ChangeLog: >> >> 2023-03-30 Martin Jambor >> >> PR ipa/109303 >> * ipa-prop.cc (determine_known_aggregate_parts): Check that the >> offset + size will be representable in unsigned int. >> >> gcc/testsuite/ChangeLog: >> >> 2023-03-30 Jakub Jelinek >> Martin Jambor >> >> PR ipa/109303 >> * gcc.dg/pr109303.c: New test. >> --- >> gcc/ipa-prop.cc | 4 +++- >> gcc/testsuite/gcc.dg/pr109303.c | 24 ++++++++++++++++++++++++ >> 2 files changed, 27 insertions(+), 1 deletion(-) >> create mode 100644 gcc/testsuite/gcc.dg/pr109303.c >> >> diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc >> index de45dbccf16..9ffd49b590c 100644 >> --- a/gcc/ipa-prop.cc >> +++ b/gcc/ipa-prop.cc >> @@ -2086,7 +2086,9 @@ determine_known_aggregate_parts (struct ipa_func_b= ody_info *fbi, >> whether its value is clobbered any other dominating one. */ >> if ((content->value.pass_through.formal_id >=3D 0 >> || content->value.pass_through.operand) >> - && !clobber_by_agg_contents_list_p (all_list, content)) >> + && !clobber_by_agg_contents_list_p (all_list, content) >> + && (content->offset + content->size - arg_offset >> + <=3D (HOST_WIDE_INT) UINT_MAX * BITS_PER_UNIT)) >> { > > it does seem a bit misplaced since after the if we add the same > 'content' to another > list anyway.=20 The other list is a clobber list, as we crawl backwards from the call statement searching for stores, we also look whether we have already encountered a store of something else to an overlapping area. In theory we could have a store to a smaller data type, where the offset + size would still fit unsigned int, be followed by a larger store, which would not. We want the large store to end up in the clobber list so that the smaller one does not. This is the place where we also calculate the size of the final heap-allocated vector, so that is why eventually I put it there. > Wouldn't a more obvious place be where we end up truncating this sum? My reasoning was that since we know we would not be able to use it, it makes sense to discard the data before we stream it from compilation to WPA. Also, when we shorten the offset type also in ipa_agg_jf_item (which is what I want to do next), this is where the check eventually needs to be. Thanks, Martin