Ping: [PATCH] Support multi-versioning on self-recursive function (ipa/92133)
Feng Xue OS
fxue@os.amperecomputing.com
Fri Nov 22 05:26:00 GMT 2019
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
More information about the Gcc-patches
mailing list