Re: [LTO] Flattening memory expressions?

[Michael Matz <matz at suse dot de>]

Hi,

On Thu, 8 Jun 2006, Richard Guenther wrote:

> > 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.

Right.  In particular if you won't emit debug information you can by this
way do away with all references to types in the insns itself.  The
variables would have no complicated type anymore, if anything perhaps a
length.  All aliasing relations would be explicit by dumping the
alias-number graph (I think in the end it would be a graph, not just a
tree), and having an alias number _per memory access_.  That would provide
for a very clear, concise and what's more frontend independend
representation of the intermediate form with aliasing info.

For purposes of merging the aliasing graphs of different compilation units
you still need to emit some type info of course (e.g. a relation of alias
number and (sub)type), but the variables itself don't all need a type
anymore (well, not composite types at least, they still can have scalar
native types, much like RTL modes plus signedness or pointerness).


Ciao,
Michael.