In the current implementation, isPromotionProfitable only checks if the call count to a direct target is no less than a certain percentage threshold of the remaining call counts that have not been promoted. This causes code size problems when the target count is small but greater than a large portion of remaining counts. E.g. target1 takes 99.9%, while target2 takes 0.1%. Both targets will be promoted and inlined, makes the function size too large, which potentially prevents it from further inlining into its callers. This patch adds another percentage threshold against the total indirect call count. If the target count needs to be no less than both thresholds in order to be promoted speculatively.
Details
Details
Diff Detail
Diff Detail
- Build Status
Buildable 8666 Build 8666: arc lint + arc unit
Event Timeline
lib/Analysis/IndirectCallPromotionAnalysis.cpp | ||
---|---|---|
47 | In your 99.9% and 0.1% case, won't the 0.1% still get promoted since it is 100% of the remaining count after promoting the 99.9% target? |
lib/Analysis/IndirectCallPromotionAnalysis.cpp | ||
---|---|---|
47 | Before the patch, yes, but with the patch, the 0.1% will be lower than the 5% threshold, thus it will not be promoted. |
Comment Actions
LGTM
lib/Analysis/IndirectCallPromotionAnalysis.cpp | ||
---|---|---|
47 | Got it - I was thinking the remaining count check was the new one, but it is essentially the old one. |
In your 99.9% and 0.1% case, won't the 0.1% still get promoted since it is 100% of the remaining count after promoting the 99.9% target?