[PATCH] D15401: Refactor threshold computation for inline cost analysis

[Chandler Carruth via llvm-commits]

chandlerc added a comment.

In http://reviews.llvm.org/D15401#311397, @eraman wrote:

> In http://reviews.llvm.org/D15401#311342, @chandlerc wrote:
>
> > I generally like the direction here, but I think you should actually go further than this.
> >
> > I think you should change the input to the cost analysis from a numeric threshold to a symbolic enum that selects between the high-level "kinds" of thresholds to use. Then you can internalize all of the logic inside of the cost analysis.
> >
> > Further, you should feel relatively free to change the behavior of the '-inline-threshold' flag. That flag is primarily a debugging aid. We don't want to flagrantly change its behavior (as that would just be annoying), we don't have any firm or hard contract around exactly how that flag is interpreted. Does that make sense?
>
>
> Passing an absolute number in inline-threshold is useful in writing tests. How about passing a symbolic enum to the getInlineCost, modify it based on properties of callsite but finally override it with -inline-threshold (or its variants) if it is explicitly passed.  Does this sound reasonable?


I'm just suggesting changing the *APIs* to deal in symbolic settings. Clearly the flag will be numeric. I'm suggested sinking the inline threshold flag into the inline cost analysis completely.


Repository:
  rL LLVM

http://reviews.llvm.org/D15401