Re: [patch] Decompose gimplify_expr

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

Hello,

> > umm, nice.  This cannot happen currently, just with your improvements to
> > alias analysis of arrays, I assume?  The consequences of our insane
> > system of representation of results of alias analysis still surprise me
> > sometimes :-)
> 
> You keep saying things like "our current alias system representation
> is insane", but you offer no constructive solutions.

do you think I just complain and did not try doing something with it?
About three times I have tried to rewrite things to something easier to
work with; always I failed because I got lost in the tree-ssa-alias
code.  Perhaps next time :-)

> Considering that the majority of our optimizations want to know, at a
> glance, which loads/stores could possibly affect each other, other
> than linking together these loads and stores through some manner
> (which is what we do, and runs into the same problems no matter how
> you link them together), and possibly providing a further
> disambiguator for the links, which is the current and future plans,
> what is your solution?
>
> What do you think a "sane" alias representation looks like?
> 
> Just alias sets that you have to query for every load and load or load and store pair you want to know about?
> 
> Such a scheme is pretty computationally expensive for optimizations to
> use to the same level they use the current information.

No, I am more or less satisfied with the virtual ssa form (*).  What
causes the problems with updating of alias analysis information (as
experienced by at least 4 different optimizers in last few months) is
the fact that the aliasing relations between loads and stores are
on-demand computed from the points-to information for pointers,
structure of memory references, etc.  This way, when say constant is
propagated to the address of a memory reference, the set of virtual
operands changes immediately, thus forcing us to update the ssa form.

I think the better approach would be not to change the virtual operands
immediately when the address of a memory reference changes.
Virtual operands should be permanent and changed only by specialized
pass that would recompute them from the current shape of the memory
references and alias analysis info.  That way, copy/constant
propagation, ivopts, and many other optimizers would not need to
worry about possibility of changing virtual operands and having to
update ssa form because of it.

The only minor drawback is that of course between say constant
propagation and the next recomputation of virtual operands, we could
not benefit from more precise alias information (say knowing that the
array reference always references the 5th element, since 5 was
propagated to the address); but with a decent alias analysis these cases
should be rare and if the virtual operands recomputation is run often
enough, that should not be a problem.

Zdenek

(*) Upto some minor details, like that it eats too much memory; but I don't
have a precise idea how to fix this.  Perhaps some mixed approach with
having virtual ssa form for some not very detailed level of alias anaslysis
(say at the current level, or perhaps one without subvars, or something
like that) + oracle working with more detailed information would be a
workable compromise between time and memory complexity, but this would
need testing to be sure.