[tree-ssa] alias analysis

[Diego Novillo]

On Tue, 2003-02-11 at 23:41, law@redhat.com wrote:
> In message <20030211203337.GA6202@tornado.toronto.redhat.com>, Diego Novillo wr
> ites:
>  >In this case we would want to split alias sets whose members
>  >cannot alias each other.  But this could quickly take us back to
>  >quadratic behaviour.  Say we have this initial alias set for X
>  >and Y:
> No more so than the current algorithm.  We can make the current algorithm
> blow up by having a different type for every variable and indirection
> for each of those types.  Suddenly you're in the "oh god this sucks"
> situation again.
> 
To get into that situation you would need a program with tens of
thousands of *different* types and tens of thousands of different
variables of those types.  If you got that kind of program, I bet you
you will lose no matter what you do.


> The reason my code tends to produce faster overall alias analysis is 
> because we avoid computing any may aliasing information for load-load
> situations.
> 
Faster than what we have now?  At this point I will need to see the
patch :)  Right now we are so fast mainly because we bag most
addressables and dereferences together.

Your patch would refine this by separating load-load aliases.  How can
that be faster?  You're adding more checks to the aliasing code :)
But I agree with you that it can be comparable in complexity.  If so,
I'm all for it.

What I would like to avoid is getting into the situation where we start
to implement various additional heuristics to the type-based analyzer
instead of relying on the PTA code.  I think I'd rather have a good PTA
implementation.  The type-based analyzer was something to get by in the
meantime, really.

> Yes, splitting the sets would work too, but that seems to be avoiding 
> the real issue -- creating too many useless alias relationships to begin
> with.
> 
Yeah, good point.


Diego.