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 C45953858402 for ; Mon, 18 Oct 2021 13:30:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C45953858402 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 7725C21A8A; Mon, 18 Oct 2021 13:30:26 +0000 (UTC) Received: from murzim.suse.de (murzim.suse.de [10.160.4.192]) (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 598EFA3B84; Mon, 18 Oct 2021 13:30:26 +0000 (UTC) Date: Mon, 18 Oct 2021 15:30:26 +0200 (CEST) From: Richard Biener To: Michael Matz cc: Richard Sandiford , Michael Matz via Gcc-patches , hubicka@ucw.cz Subject: Re: [PATCH][RFC] Introduce TREE_AOREFWRAP to cache ao_ref in the IL In-Reply-To: Message-ID: <69qs2nq-nns6-r5o3-71s3-433nq886osrn@fhfr.qr> References: <3313269o-5444-9142-o8ro-1s59r67083pq@fhfr.qr> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.0 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:30:29 -0000 On Mon, 18 Oct 2021, Michael Matz wrote: > 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). Yes, I suspect in the end I'd use two bits to optimize this case. > 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 the main issue is that I consider none of the discussed approaches nice (or well-designed), so I went for the one that appears to be least intrusive (the concatenating and bit-indication). That said, I'm probably going to codify the on-the-side (optional) hashtable variant as well which is at least well-designed but might have a disadvantage in the larger constant overhead and principle difficulties in carrying info across passes and a necessarily more explicit invalidation API. Note all prototypes missed the verification part (that info is not stale and reasonably up-to-date). The real answer might of course be to invent the "proper" MEM_REF tree that has fast access to ao_ref-style info as well as being able to encode the important parts of the access path. Richard.