Ping: [PATCH] Support multi-versioning on self-recursive function (ipa/92133)

[Feng Xue OS <fxue@os.amperecomputing.com>]

Honza, Martin,

  Hope your more comments on this patch. Not sure you base option on it. I think this can be a start point for
recursive versioning. And later we definitely need further cost-model tuning not only on this, but also whole
 ipa-cp to enable more aggressive cloning.

Thanks,
Feng

________________________________________
From: Feng Xue OS <fxue@os.amperecomputing.com>
Sent: Friday, November 15, 2019 11:32 PM
To: Jan Hubicka
Cc: luoxhu; gcc-patches@gcc.gnu.org; Martin Jambor
Subject: Re: [PATCH] Support multi-versioning on self-recursive function (ipa/92133)

Honza,

   I made some changes: do not penalize self-recursive function, and add --param ipa-cp-min-recursive-probability, similar to recursive inline. Please review this new one.

Thanks,
Feng

________________________________________
From: Jan Hubicka <hubicka@ucw.cz>
Sent: Friday, November 15, 2019 4:33 AM
To: Feng Xue OS
Cc: luoxhu; gcc-patches@gcc.gnu.org; Martin Jambor
Subject: Re: [PATCH] Support multi-versioning on self-recursive function (ipa/92133)

> >> Cost model used by self-recursive cloning is mainly based on existing stuffs
> >> in ipa-cp cloning, size growth and time benefit are considered. But since
> >> recursive cloning is a more aggressive cloning, we will actually have another
> >> problem, which is opposite to your concern.  By default, current parameter
> >> set used to control ipa-cp and recursive-inliner gives priority to code size,
> >> not completely for performance. This makes ipa-cp behave somewhat
>
> > Yes, for a while the cost model is quite off.  On Firefox it does just
> > few clonings where code size increases so it desprately needs retuning.
>
> > But since rescursive cloning is quite a different case from normal one,
> > perhaps having independent set of limits would help in particular ...
> I did consider this way, but this seems to be contradictory for normal
> and recursive cloning.

We could definitly discuss cost model incrementally. It is safe to do
what you do currently (rely on the existing ipa-cp's overconservative
heuristics).

>
> > > Do you have some data on code size/performance effects of this change?
> > For spec2017, no obvious code size and performance change with default setting.
> > Specifically, for exchange2, with ipa-cp-eval-threshold=1 and ipcp-unit-growth=80,
> > performance +31%, size +7%, on aarch64.
>
> > ... it will help here since ipa-cp-eval-threshold value needed are quite off of what we need to do.
>
> > I wonder about the 80% of unit growth which is also more than we can
> > enable by default.  How it comes the overal size change is only 7%?
> 343624 -> 365632 (this contains debug info, -g)    recursion-depth=8
> 273488 -> 273760 (no debug info)   recursion-depth=8

What seems bit odd is that ipcp's metrics ends up with 80% code growth.
I will try to look into it and see if I can think better what to do
about the costs.

Honza