On 10/30/20 7:01 AM, Richard Biener wrote: > > It's not that more / different inlining inherently exposes _more_ > false positives in the middle-end warnings. They simply expose > others and the GCC codebase is cleansed (by those who change > inliner heuristics / tunings) from those by either fixing the analysis > or modifying the code (like putting in initializers).
Right. The change in heuristics inherently perturb the middle end warnings. It has been and continues to be a source of significant headaches in Fedora. > Whether thats a good or bad tradeoff is up to the port maintainers > but I usually urge port maintainers to _not_ change defaults > of parameters affecting (relatively) early IL because it makes > a testing done on major platforms not be transferable, in terms > of coverage, to yours. I'd advise against it as well. > > I also don't believe the telltale that the high inliner limits are > necessary to get comparable performance. Note that these > were re-tuned only quite some time ago and they are not > tuned relative to the current default but tuned to absolute values > and thus do not vary when the defaults are re-tuned (which they > are for each release). Precisely. Honza re-tunes the parameters for nearly every release so that they reflect the various tradeoffs of our optimizer/analysis implementation for each release. When backends override, they don't get any of that benefit and ultimately it makes more work for others at the distro level. Jeff
