Re: [LTO] Flattening memory expressions?

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> > >>> 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 :)
> > > 
> > > What type the first operand would be could be a one-bit flag in the
> > > MEM_REF itself.  I.e. if there's an implicit INDIRECT_REF around the
> > > first operand, or not.  The important part is only that the target
> > > address of that memory reference is computable completely trivially,
> > > namely by A + i, where A is either a or &a depending on that flag.  
> > > And the more important thing anyway is that alias information of this
> > > specific mem reference encoded therein.
> > 
> > Not for data dependence it's not. :)
> 
> You mean tests based on the actual index vector, instead of the final 
> offset vector?  I still sometimes think that one should be able to 
> recover the index vector reasonably well, when given only offsets (and 
> perhaps adjusted bases).  It's a tradeoff of having only one way to 
> express memory accesses (which I find quite sexy) and having to do a 
> bit more work when trying to get at the offsets.

by this kind of lowering, you lose quite a lot of information.  For
example, a[i][j] lowers to something like
offset = step1 * i + step2 * j; MEM(a, offset).

1) Recovering the index vector is not easy, as the optimizations may
   change this code a lot.  Even if you find an expression that looks
   like MEM(a, step1 * i + step2 * j), you have no good way to know that
   this was not originally a[i + 1][j - step1/step2].
2) If "a" has constant bounds, before the lowering you could use these
   bounds for example to estimate # of iterations of a loop.  From
   similar reasons as in the last statement, this is impossible after
   lowering.
3) There may be some uses of the fact that we know that the arithmetics
   in step1 * i + step2 * j cannot overflow (which is at the moment
   impossible to remember after lowering), although I cannot think about
   a good example just now.

Zdenek