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.
