Re: [tree-ssa] alias analysis

[Daniel Berlin <dberlin at dberlin dot org>]

On Thursday, February 13, 2003, at 10:27  AM, Diego Novillo wrote:

> On Wed, 2003-02-12 at 02:17, Daniel Berlin wrote:
>
> > On a random note, do either of you plan on making calls to may_alias_p
> > from outside of tree-dfa.c anymore?
> Yes, of course.
Errr, you removed them all and made may_alias_p static, and told me you 
wanted to make it private. That's why I asked.
This is a completely opposite answer than what you said a few days ago.

>  I keep wondering why you removed the call to PTA from
> tree-dfa.c.
I didn't, look again.

>  Ultimately I want to be able to use PTA.  The only reason
> why we have a type-based analyzer was because we don't yet have a fully
> working PTA one.
We shouldn't be having an analyzer that *only* uses PTA or *only* uses 
TBAA.
That's silly.
They can work in concert, as they do now.
PTA is still used to disambiguate the aliases.

> > I had moved the freeing of PTA memory to SSA deletion time when Diego
> > was doing alias tags, and using may_alias_p in tree-ssa.c, but if it's
> > not going to be called during SSA building anymore, i'll move the
> > freeing of PTA memory back to where it used to be.
> Please put it back.
Put what back?

I'm not sure you quite understand what I asked above.

Before (as in before  we had alias leaders, months ago) we had

create pta info
do may-aliasing
delete pta info
create ssa
optimize
delete ssa

When we had alias leaders (months ago) we had to do
create pta info
do may-aliasing
create ssa
optimize
delete ssa
delete pta info

because you had calls to may_alias_p (which used pta info) from the 
"create ssa" steps.

Now we still have
create pta info
do-may-aliasing
create ssa
optimize
delete ssa
delete pta info

but you've removed all the calls to may_alias_p and made it static.

If this is how it will stay, we can move back to doing
create pta info
do may-aliasing
delete pta info
create ssa
optimize
delete ssa

again.

That's all i've asked.

>   I thought I had neatly separated what we do when
> -ftree-points-to is given and when it's not.  I don't know why you
> removed it.
Because it's broken that way (Jeff's changes broke it, AFAICT), and 
because it's too memory intensive if you create explicit may-alias sets 
because of global var aliasing.  It's not usable that way.  I've got 
figures, but they aren't pretty.
It's not a fixable problem.  We'll have to create some kind of set to 
reduce the memory requirements.

> If it's because tree-dfa.c doesn't use it properly, let's fix that.
>  I
> want to be able to do both.
We still use PTA to disambiguate the sets created now if it's available.
We just don't create explicit may aliases with no sets anymore.
The quality of the information actually hasn't changed with what we do 
now, or else i wouldn't have done it.
>   Type-based should be *very* fast and rather
> stupid.  PTA can be a bit slower (not necessarily, only if it wants to
> be), but more precise.
It still is 99.99% as precise as it was before.

You seem to think we don't use PTA anymore.
This is not the case at all.
I've only removed broken code that won't do something we can use 
anyway, and can't be made to do something we can use.

> Diego.