Richard Guenther wrote: > 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.
So if you have MEM_REF(INDIRECT_REF(a),i,0), you really haven't done any better in removing recursion :) > The MEM_REF would also contain an alias tag for > easy oracle queries Tag has some meaning in our current structure. I'd support some sort of generic token that associates the alias info with it, however.
