From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 829473858D28 for ; Tue, 23 Nov 2021 15:53:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 829473858D28 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-450-7t9EuxCkOhKFI8wgr4D6Eg-1; Tue, 23 Nov 2021 10:53:05 -0500 X-MC-Unique: 7t9EuxCkOhKFI8wgr4D6Eg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D17D9A40C0; Tue, 23 Nov 2021 15:53:04 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6BB876784B; Tue, 23 Nov 2021 15:53:03 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 1ANFqtdu2111668 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 23 Nov 2021 16:52:55 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 1ANFqsaZ2111667; Tue, 23 Nov 2021 16:52:54 +0100 Date: Tue, 23 Nov 2021 16:52:54 +0100 From: Jakub Jelinek To: Siddhesh Poyarekar Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 06/10] tree-object-size: Support dynamic sizes in conditions Message-ID: <20211123155254.GA2646553@tucnak> Reply-To: Jakub Jelinek References: <20211109190137.1107736-1-siddhesh@gotplt.org> <20211109190137.1107736-7-siddhesh@gotplt.org> <20211123151252.GZ2646553@tucnak> <773d3a85-b78c-c67e-c190-b9b128d3738b@gotplt.org> MIME-Version: 1.0 In-Reply-To: <773d3a85-b78c-c67e-c190-b9b128d3738b@gotplt.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 15:53:10 -0000 On Tue, Nov 23, 2021 at 09:06:49PM +0530, Siddhesh Poyarekar wrote: > On 11/23/21 20:42, Jakub Jelinek wrote: > > On Wed, Nov 10, 2021 at 12:31:32AM +0530, Siddhesh Poyarekar wrote: > > > (object_sizes_execute): Don't insert min/max for dynamic sizes. > > > > I'm worried about this. > > I'd say what we might want to do is in the early pass for __bdos > > compute actually __bos (i.e. the static one) and add MIN_EXPR/MAX_EXPR > > for the result of the __bdos call from the second pass with the > > statically computed value. > > > > The reason for the MIN_EXPR/MAX_EXPR stuff is that GIMPLE optimizations > > can remove exact ADDR_EXPRs with detailed COMPONENT_REF etc. access paths > > in it, so during the late objsz2 pass the subobject modes don't work > > reliably anymore. But the subobject knowledge should be the same between > > the static and dynamic evaluation... > > So in the dynamic case we almost always end up with the right expression in > objsz1, except in cases where late optimizations make available information > that wasn't available earlier. How about putting in a MIN_EXPR/MAX_EXPR if > we *fail* to get the subobject size instead? I don't think that is the case, perhaps for trivial testcases yes when early inlining inlines the fortification always_inline functions and everything appears in a single function. The primary reason for objsz2 being done later is that it is after inlining, IPA optimizations and some optimization passes that clean up after those. But at the same time it is after too many optimizations that could have broken the exact subobject details. But very often in objsz1 you'll just see const char *p argument and only inlining will reveal how that was allocated etc. Evaluating __bdos in both passes is undesirable, certainly for the same SSA_NAME, but even for different SSA_NAMEs, if everything is done in a single pass it can easily share temporaries (object sizes for SSA_NAMEs it uses), while if some __bdos is evaluated early and other late, we'll need to hope further optimizations CSE those. Jakub