[llvm-commits] PATCH: First step in refactoring the threshold used in InlineCost computation

[Chris Lattner]

On Mar 15, 2012, at 2:08 AM, Chandler Carruth wrote:
> This is a generic refactoring patch that shouldn't change any functionality. Just sinking the threshold into the inline cost analysis, and cleaning up the API of the InlineCost objects so that they can wrap up both the cost and the threshold.

Thanks for the background, I think that direction makes a lot of sense to pursue.

Here are some random thoughts (not all your fault :)

1. Why does InlineCost represent its CostKind as a 2-bit bitfield instead of as two sentinel values?  If we use CK_Never = MAXUINT and CK_Always as MAXUINT-1, then we get a simpler (and probably slightly faster) structure than a 30/2 bit bitfield thing.

2. Putting the target cost into InlineCost is weird.  It would make more sense (to me) for getInlineCost() to take the max threshold: if the call site exceeded the cost, it would just return CK_Never, or a new CK_ExceededCost sentinel or something.

3. getInlineFudgeFactor really shouldn't return floats.  Using floating point math is a sure recipe for the compiler behaving differently on different hosts (e.g. excess precision on x87 hosts).  The code looks like it could be easily modified to return a fixed-point integer or something.

-Chris