> >> 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
