From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.25]) by sourceware.org (Postfix) with ESMTPS id 6FCCA3858D39 for ; Fri, 26 Nov 2021 18:07:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6FCCA3858D39 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 2C51D8201CC; Fri, 26 Nov 2021 18:07:44 +0000 (UTC) Received: from pdx1-sub0-mail-a307.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id ADDE78214E6; Fri, 26 Nov 2021 18:07:43 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from pdx1-sub0-mail-a307.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.109.250.31 (trex/6.4.3); Fri, 26 Nov 2021 18:07:44 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Rock-Wide-Eyed: 6654b33b5f7fda92_1637950063985_1833369806 X-MC-Loop-Signature: 1637950063984:964429 X-MC-Ingress-Time: 1637950063984 Received: from [192.168.1.174] (unknown [1.186.223.60]) (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-a307.dreamhost.com (Postfix) with ESMTPSA id 4J12ld6kC8z35; Fri, 26 Nov 2021 10:07:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gotplt.org; s=gotplt.org; t=1637950063; bh=qqNCIs001S77KeOO4PVVsXJ9kUg=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=IgN8MckN8HteaxC3inECJZkfm+JtYzwMImV+DWw9v7a5fbFLPbQMpL244oNypg/fO XH8/+rODXqRZI/TDDQIEOaAs1MicpsFWBwcSEHW5PtfTkvYUQYugcvB6A63DoBgeez EIvxzE8ZR8npOcm2/EXSB5ijuvcV+B08GavW74Jw= Message-ID: <087dbc65-c517-3546-51be-4b42748033c6@gotplt.org> Date: Fri, 26 Nov 2021 23:37: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 v3 3/8] tree-object-size: Save sizes as trees and support negative offsets Content-Language: en-US To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org References: <20211109190137.1107736-1-siddhesh@gotplt.org> <20211126052851.2176408-1-siddhesh@gotplt.org> <20211126052851.2176408-4-siddhesh@gotplt.org> <20211126165634.GM2646553@tucnak> <20211126180428.GO2646553@tucnak> From: Siddhesh Poyarekar In-Reply-To: <20211126180428.GO2646553@tucnak> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3033.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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: Fri, 26 Nov 2021 18:07:49 -0000 On 11/26/21 23:34, Jakub Jelinek wrote: > On Fri, Nov 26, 2021 at 11:29:41PM +0530, Siddhesh Poyarekar wrote: >>>> The trees in object_sizes are each a TREE_VEC with the first element >>>> being the bytes from the pointer to the end of the object and the >>>> second, the size of the whole object. This allows analysis of negative >>>> offsets, which can now be allowed to the extent of the object bounds. >>>> Tests have been added to verify that it actually works. >>> >>> If you need pairs of trees, just use pairs of trees, using TREE_VEC for it >>> will create lots of extra garbage. >>> Either std::pair, but most likely gengtype won't handle that >>> right, so just create your own >>> struct GTY(()) whatever { >>> /* Comment explaining what it is. */ >>> tree whatever1; >>> /* Comment explaining what it is. */ >>> tree whatever2; >>> }; >>> and if that needs to go into e.g. object_sizes vectors, use vec. >> >> Got it, I'll make a new struct GTY(()). I'm also using TREE_VEC to store >> PHI nodes args and the result (in patch 5/8) until they're emitted in >> gimplify_size_expressions. It needs to be a tree since it would be stored >> in whatever1 and whatever2, would that be acceptable use? > > Maybe yes, I'll need to look at it. What I didn't like is using TREE_VEC > for something that will come in pairs all the time. Ah ok, I understand your concern better now, thanks. Siddhesh