[PATCH] D22261: [InlineCost] Set minsize inline threshold to 0

[Philip Reames via llvm-commits]

reames added a subscriber: reames.
reames added a comment.

In https://reviews.llvm.org/D22261#499678, @chandlerc wrote:

> I really think we need to understand why you see this swing in size between two very close thresholds of 0 and 25. My suspicion is that we have some flaw in how we calculate the cost of inlining a function which just calls another function with (perhaps a permutation of) the arguments it is called with. Fixing that cost computation so that it (correctly) is modeled as 0 cost seems really valuable *outside* of -Oz as well.


I want to second what Chandler said here.  If we have a testing methodology which can help us fix cases where we got our cost model wrong and are thus more sensitive to the threshold values than we should be, we should exploit that for all it's worth.

Also, I wouldn't be surprised if simply writing some manual test cases for argument shuffling and other idiomatic small functions with an inline-threshold set to zero were to find a few cases.  Some targeted test writing (as opposed to benchmark analysis) might be really useful.

Also, adding a hook to the inliner which causes it to print inline candidates which *did* get inlined with a 25 threshold, but had a cost above 0 would be a quick way to find a bunch of these cases.  We've applied that a couple of times in our tree with pretty good success.  Actually, a "print-inline-close-to-threshold" option might be a generically useful analysis tool.


https://reviews.llvm.org/D22261