Improve handling of memory operands in ipa-icf 4/4

Jan Hubicka hubicka@ucw.cz
Thu Nov 19 10:14:03 GMT 2020


> On 11/16/20 12:20 AM, Jan Hubicka wrote:
> > This is controlled by -fipa-icf-alias-sets
> > 
> > The patch drops too early, so we may end up processing function twice.  Also if
> > merging is not performed we lose code quality for no win (this is rare case).
> > My original plan was to remember the mismatched parameter and apply them only
> > after merging decisions are finished, but I was not sure how to do that in
> > ipa-icf.  In particular we need to ensure transitivity. In particular if
> > function foo is merged to bar, we also need to be sure that we dropped
> > base alias setsin functions tht are called by bar even if they themselves
> > are not merged. Martin, is there easy way to implement this on top of current ICF?
> 
> Well, you will need to create a set of merged functions and then traverse all
> callers of these (via cgraph_node callers). It should not be so difficult, or?

Well, imagine you have function A1 and A2 
and calls A1->B2
and       A2->B3
and there is also B3.

Now A1 is ICF equivalent to A2
and also B1,B2,B3 are ICF equivalent if some TBAA info is dropped.

ICF merges A2 to A1
it also considers to merge B2,B3 to B1 but concludes it is not benefical
at the very end (because some of them have address taken and
constructing wrapper is too expensive)

The comparsions done are
 B1:B2
 B1:B3
 A1:A2
So after comparing we have info what to drop in B1 to make merging B2->B1
and B3->B1 valid.  We also have info what to drop in B2 to make B1->B2
valid and in B3 to make B3->B1 valid.

But we meed to drop info in B2 to make B3->B2 valid to make call path
alias A2 of A1->B2 safe.

Honza


More information about the Gcc-patches mailing list