On 6/8/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
When I originally thought of flattening the data structures for
representing GIMPLE, I had not really contemplated the idea of totally
lowering the memory expressions represented by ARRAY_REF and COMPONENT_REF.
However, as Kenny pointed out today, it may be useful for us to
completely simplify these expressions to remove their recursive
structure. Something like:
ARRAY_REF : ID [ VAL ]
COMPONENT_REF : ID . ID
| INDIRECT_REF . ID
INDIRECT_REF : * ID
We would probably need INDIRECT_REFs in COMPONENT_REF nodes to avoid
lots of memory copying.
The rationale is that by removing the recursiveness of these
expressions, it would make it easier to emit the LTO bytecodes without
resorting to a stack machine.
These memory expressions are the only ones that I think would need to be
simplifed. All the other GIMPLE expressions are already flat enough for
LTO purposes.
This flattening, however, could bring debug code generation issues. I'm
not sure.
Please don't get too fixated on the above pseudo-code. I have not
thought about this through in detail. I just want to bring this up,
particularly for folks doing data dependency. Perhaps we need different
expressions altogether, we don't need to stick to the current scheme if
it's not sufficiently useful.
Thoughts?
We (me and Matz) thought over this as well and concluded it would be
nice to have
- MEM_REF ( base, offset, alias_tag )
with base being either some memory object or an INDIRECT_REF of a pointer and
be done with that tree code. The MEM_REF would also contain an alias tag for
easy oracle queries, like an integer we get from get_alias_set now.
Sticking that
to the actual MEM_REF sounded particularly nice - also the frontends
can this way
communicate aliasing semantics down to the middle-end in addition to TBAA stuff.
So, yes, we like complete lowering as 90% of optimization passes deal with
base and offset using get_inner_reference or friends anyway.
Richard.
