[PATCH] D53405: [Inliner] Attempt to more accurately model the cost of loops at minsize

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

> (but can cause problems for cases where the blocks are not in the form they will appear in assembly).

I'm not sure what sort of issue you're running into here?

------

Reducing the call penalty seems like it's a good idea if our inline modeling has improved since it was set.  But I'm a little cautious about messing with it on its own.  If you decreased both the call penalty and the overall threshold at the same time, it would have the effect of encouraging inlining for functions which call other functions; if that has a good effect on codesize, we should do that.  If that's not the effect we want, we should probably just change the overall threshold instead.

------

The PHI handling change is kind of ugly, but I guess it's roughly right.  Not sure we want to guard it with minsize, specifically; it should do the right thing at higher inlining levels.

-------

If we're going to start spending time making changes like this that slightly tweak the inline cost for the sake of minsize, I think we need to be a bit more methodical in terms of testing, so we don't end up playing tug-of-war with inliner tweaks that affect different codebases in different ways.  For example, having a series of testcases with calls to small functions near the various thresholds, accompanied by actual measurements of the codesize on a couple targets, so we can be confident that tweaks are actually profitable.  For other optimization levels, inlining is more about capturing big optimization opportunities, as opposed to the exact cost of various instructions, so it doesn't matter as much, but I think spending more time to construct tests will pay off for -Oz in particular.  We currently have very little test coverage for minsize inlining.


https://reviews.llvm.org/D53405