From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from camel.birch.relay.mailchannels.net (camel.birch.relay.mailchannels.net [23.83.209.29]) by sourceware.org (Postfix) with ESMTPS id 4045E3857C4B for ; Tue, 23 Nov 2021 15:38:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4045E3857C4B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 91647120AC3; Tue, 23 Nov 2021 15:38:42 +0000 (UTC) Received: from pdx1-sub0-mail-a306.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E8C53120F4D; Tue, 23 Nov 2021 15:38:41 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a306.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.111.70.137 (trex/6.4.3); Tue, 23 Nov 2021 15:38:42 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Illustrious-Troubled: 004dd29d5fb13e41_1637681922307_890356635 X-MC-Loop-Signature: 1637681922307:738499028 X-MC-Ingress-Time: 1637681922307 Received: from [192.168.1.174] (unknown [1.186.224.140]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a306.dreamhost.com (Postfix) with ESMTPSA id 4Hz7b43RsMz2x; Tue, 23 Nov 2021 07:38:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gotplt.org; s=gotplt.org; t=1637681921; bh=J78RUfFBaCPLBqYtkNAnrqd6d8I=; h=Date:Subject:From:To:Cc:Content-Type:Content-Transfer-Encoding; b=jyjHsV9Omoh2fmJ5IsYEc8H5sdXBm7oNgkY8OnFcDLJI2whf5FAZqiKTatqu+aIJe jBjXQLL2Nqw7pPTmZfs06rosC788orY7sL/XYCqOLZQ/EIZRwgO1fB6jzDHAIVAHUQ G/+p3eG3DrhxktRXQHPs5rQOInOwkfMZXGI8Jyi8= Message-ID: <667a586c-7a43-b711-09e9-91a40cdd7072@gotplt.org> Date: Tue, 23 Nov 2021 21:08:35 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 Subject: Re: [PATCH 06/10] tree-object-size: Support dynamic sizes in conditions Content-Language: en-US From: Siddhesh Poyarekar To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org References: <20211109190137.1107736-1-siddhesh@gotplt.org> <20211109190137.1107736-7-siddhesh@gotplt.org> <20211123151252.GZ2646553@tucnak> <773d3a85-b78c-c67e-c190-b9b128d3738b@gotplt.org> In-Reply-To: <773d3a85-b78c-c67e-c190-b9b128d3738b@gotplt.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3030.2 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, 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:38:48 -0000 On 11/23/21 21:06, 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? Actually if we don't get a dynamic expression it's unlikely that we'll get a static size either, so I'm not sure if MIN_EXPR/MAX_EXPR will actually do anything useful. Siddhesh