This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [LTO] Flattening memory expressions?

Richard Guenther wrote:
> On 6/8/06, Diego Novillo <> 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:
>>                 | 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]