This has some minor optimizations to shouldBeDeferred. This is not
strictly NFC because the early exit inside the loop assumes
TotalSecondaryCost is monotonically non-decreasing, which is not true if
the threshold used by CostAnalyzer is negative. AFAICT the thresholds do
not go below 0 for the default values of the various options we use.
Details
- Reviewers
chandlerc
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 26410 Build 26409: arc lint + arc unit
Event Timeline
Reviving this old patch as Wei recently noticed a case where a large function with many callees and many callers spent significant amount of time in shouldBeDeferred. This was triggered by change in profile causing many callees to be inlined into this large function.
Nice, LGTM!
Does it make sense to add a (very early) assert that the thresholds are non-negative? I agree with you that it shouldn't be happening and it seems like a good invariant to enforce. Can of course be a follow-up patch.
lib/Transforms/IPO/Inliner.cpp | ||
---|---|---|
340 | Despite the old variable's name, this should be ApplyLastCallBonus. |
I don't know if we make implicit assumptions about threshold being positive, but I agree this seems a reasonable invariant to enforce. I turned on an assert and found that a test case that passes --inline-threshold=-2 breaks. I will add the assert in a follow-up patch along with the fix to the test.
The instance Wei observed didn't have multiple callers. I mis-understood the case and Wei thought this patch fixed the issue, but it actually didn't. Still, I think this is a useful fix.
Despite the old variable's name, this should be ApplyLastCallBonus.