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 BE5B33858C2C for ; Tue, 23 Nov 2021 15:13:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BE5B33858C2C 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-500-GXDIDxeuNFunoBHkuqCsAA-1; Tue, 23 Nov 2021 10:12:58 -0500 X-MC-Unique: GXDIDxeuNFunoBHkuqCsAA-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 2D4EB57201; Tue, 23 Nov 2021 15:12:57 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BDAAE418E; Tue, 23 Nov 2021 15:12:56 +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 1ANFCr7S2111479 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 23 Nov 2021 16:12:54 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 1ANFCrJF2111478; Tue, 23 Nov 2021 16:12:53 +0100 Date: Tue, 23 Nov 2021 16:12:52 +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: <20211123151252.GZ2646553@tucnak> Reply-To: Jakub Jelinek References: <20211109190137.1107736-1-siddhesh@gotplt.org> <20211109190137.1107736-7-siddhesh@gotplt.org> MIME-Version: 1.0 In-Reply-To: <20211109190137.1107736-7-siddhesh@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:13:03 -0000 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... Jakub