Hello,
On Thu, 14 Oct 2021, Richard Biener wrote:
> > So, at _this_ write-through of the email I think I like the above idea
> > best: make ao_ref be a tree (at least its storage, because it currently
> > is a one-member-function class), make ao_ref.volatile_p be
> > tree_base.volatile_flag (hence TREE_VOLATILE(ao_ref)) (this reduces
> > sizeof(ao_ref) by 8), increase all nr-of-operand of each tcc_reference by
> > 1, and make TREE_AO_REF(reftree) be "TREE_OPERAND(reftree,
> > TREE_CODE_LENGTH(reftree) - 1)", i.e. the last operand of such
> > tcc_reference tree.
>
> Hmm. I'm not sure that's really something I like - it's especially
> quite some heavy lifting while at the same time lacking true boldness
> as to changing the representation of memory refs ;)
Well, it would at least enable such changes later in an orderly fashion.
> That said - I've prototyped the TREE_ASM_WRITTEN way now because it's
> even simpler than the original TREE_AOREFWRAP approach, see below.
>
> Note that I'm not embedding it into the tree structure, I'm merely
> using the same allocation to store two objects, the outermost ref
> and the ao_ref associated with it. Quote:
>
> + size_t length = tree_code_size (TREE_CODE (lhs));
> + if (!TREE_ASM_WRITTEN (lhs))
> + {
> + tree alt_lhs
> + = ggc_alloc_cleared_tree_node_stat (length + sizeof (ao_ref));
> + memcpy (alt_lhs, lhs, length);
> + TREE_ASM_WRITTEN (alt_lhs) = 1;
> + *ref = new ((char *)alt_lhs + length) ao_ref;
You need to ensure that alt_lhs+length is properly aligned for ao_ref, but
yeah, for a hack that works. If you really want to go that way you need
good comments about this hack. It's really somewhat worrisome that the
size of the allocation depends on a bit in tree_base.
(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 :) )
Ciao,
Michael.
