Re: Add few cases to operand_equal_p

[Jan Hubicka <hubicka at ucw dot cz>]

> Yes, so this shows using original bodies for inlining isn't the issue.
> The issue is that we can't really ignore TBAA (completely?) when
> merging function bodies, independent of any issues that pop up
> when inlining merged bodies.  We should have the above as testcase

Yes.

> in the testsuite (with both source orders of a and b to make sure
> ICF will eventually pick both).
> 
> Now the question is whether we can in some way still merge the above
> two functions and retain (some) TBAA, like by making sure to adjust
> all MEM_REFs to use union { type1; type2; } for the TBAA type... (eh).

I discussed the plan with Martin.  I think the first step would be to make this
work at -Os in the following way
 1) we will do unification ignoring alias sets completely
 2) once equivalneces are stablished we verify what can be unified (icf_merge is not always
    doable) and fix the unification decisions.
 3) For every function that remains in the program we produce list of other
    functions that was merged into it.
    For each of it we make sure that alias sets are conservative dropping to 0
    where neccesary.
 4) we apply the redirectinos and throw away original bodies (or keep them for inlining
    to improve debug info)

This scheme is useful to merge other metadata, too (such as jump functions).
Now for -O2 it will be harder to decide whether punt merging or drop alias set.  We can
even introduce the artificial union (as alias sets only or as types themselves) and
do just as much of TBAA punting as needed.

But I would build from experience above.
> 
> No longer globbing all pointer types will even make std::vector<ptr>
> no longer mergeable...

Yep, we do not merge most of tyime anyway, as eventually ipa-icf gets sily enough
to compare the pointed-to type or it tries to match FIELD_DECL references exactly.
I plan to slowly work on that once we settle down currently open topics ;)

Honza
> 
> Richard.
> 
> > > 
> > > > I also do not believe that TBAA should be function local.  I believe it is
> > > > useful to propagate stuff interprocedurally, like ipa-prop could be able to
> > > > propagate this:
> > > > 
> > > > long *ptr1;
> > > > int *ptr2;
> > > > t(int *ptr)
> > > > {
> > > >   return *ptr;
> > > > }
> > > > wrap(int *ptr)
> > > > {
> > > >  *ptr1=1;
> > > > }
> > > > call()
> > > > {
> > > >   return wrap (*ptr2);
> > > > }
> > > > 
> > > > and we could have ipa-reference style pass that collect alias sets 
> > > > read/written by a function and uses it during local optimization to 
> > > > figure out if there is a true dependence between function call and 
> > > > memory store.
> > > 
> > > Sure, but after ICF there is no IPA propagation...
> > Doesn't matter if you propagate before or after ICF. If you do before, ICF
> > would need to match/merge the alias set in optimization summary to be sure that
> > the functions are same.
> > 
> > Honza
> > > 
> > > Richard.
> > > 
> > > -- 
> > > Richard Biener <rguenther@suse.de>
> > > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)
> > 
> > 
> 
> -- 
> Richard Biener <rguenther@suse.de>
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)