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 09B293858400 for ; Mon, 18 Oct 2021 13:14:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 09B293858400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id B66A421A6B; Mon, 18 Oct 2021 13:14:51 +0000 (UTC) Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 9B640A3B89; Mon, 18 Oct 2021 13:14:51 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 8BD59656D; Mon, 18 Oct 2021 13:14:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 8A3FF6560; Mon, 18 Oct 2021 13:14:51 +0000 (UTC) Date: Mon, 18 Oct 2021 13:14:51 +0000 (UTC) From: Michael Matz To: Richard Sandiford cc: Michael Matz via Gcc-patches , Richard Biener , hubicka@ucw.cz Subject: Re: [PATCH][RFC] Introduce TREE_AOREFWRAP to cache ao_ref in the IL In-Reply-To: Message-ID: References: <3313269o-5444-9142-o8ro-1s59r67083pq@fhfr.qr> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Mon, 18 Oct 2021 13:14:54 -0000 Hello, On Mon, 18 Oct 2021, Richard Sandiford wrote: > > (It's a really cute hack that works as a micro optimization, the question > > is, do we really need to go there already, are all other less hacky > > approaches not bringing similar improvements? The cuter the hacks the > > less often they pay off in the long run of production software :) ) > > FWIW, having been guilty of adding a similar hack(?) to SYMBOL_REFs > for block_symbol, I like the approach of concatenating/combining structures > based on flags. The problem is that if you unset the flag you can't free the (now useless) storage. What's worse is that you can't even reuse it anymore, because you lost the knowledge that it exists (except if you want to use another flag to note that). It's of course obvious, but it helps to spell that out if we want to argue about ... > The main tree and rtl types have too much baggage and ... baggage. What you actually gain by associating different info pieces by address (e.g. concatenate allocations) is that you don't need to refer to one from the other, that's the space you spare, not anything inherent in the structures (which remain to have the members they would have anyway). So, you basically trade one pointer (or index), which would possibly be optional, with address association and inflexibility (with the impossibility to manage both pieces individually: you can't free the second piece, and you can't add the second piece post-allocation). It might be a good trade off sometimes, but in the abstract it's not a good design. Regarding trees and space: to make something a tree you need 8 bytes and get a number of flags, and an arbitrary 4-byte blob in return. I don't see that as much baggage. We could reduce it further by splitting the arbitrary union and the tree_code+flags parts. Especially for things referred to from tree_exp it makes sense to try making them trees themself. > so I think there are some things that are better represented outside > of them. > > I suppose cselib VALUE rtxes are also similar, although they're more > of a special case, since cselib data doesn't survive between passes. Ciao, Michael.