[llvm] r311371 - [InlineCost] Add cl::opt to allow full inline cost to be computed for debugging purposes.

[Davide Italiano via llvm-commits]

On Fri, Aug 25, 2017 at 1:16 PM, Davide Italiano <davide at freebsd.org> wrote:
> On Fri, Aug 25, 2017 at 1:11 PM, Davide Italiano <davide at freebsd.org> wrote:
>> On Mon, Aug 21, 2017 at 1:00 PM, Haicheng Wu via llvm-commits
>> <llvm-commits at lists.llvm.org> wrote:
>>> Author: haicheng
>>> Date: Mon Aug 21 13:00:09 2017
>>> New Revision: 311371
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=311371&view=rev
>>> Log:
>>> [InlineCost] Add cl::opt to allow full inline cost to be computed for debugging purposes.
>>>
>>> Currently, the inline cost model will bail once the inline cost exceeds the
>>> inline threshold in order to avoid unnecessary compile-time. However, when
>>> debugging it is useful to compute the full cost, so this command line option
>>> is added to override the default behavior.
>>>
>>> I took over this work from Chad Rosier (mcrosier at codeaurora.org).
>>>
>>
>> This causes a non-linear increase in the time spent in the inliner for
>> us, even with optimization remarks disabled.
>> real    0m2.889s
>> vs
>> real    0m30.429s
>>
>> I'm under the impression the issue is that for the legacy pass manager
>> we create an ORE object on-the-fly (as the inliner is a CGSCC pass,
>> and ORE is a FunctionPass analysis), so ORE is always non-null and we
>> compute the inlineCost in every case. For the new PM, we can rely on
>> proxying, but in the current infrastructure I'm not aware of an easy
>> way of obtaining function passes from outer units of IR.
>> Adam/Chandler, thoughts?
>>
>> If nothing comes up, I'm going to pass null instead of ORE in
>> InlineSimple to recover from the hit (the feature will be still
>> available in the new PM, where we have a much better infrastructure
>> for the purpose).
>>
>> Thanks,
>>
>
> Alternatively, maybe, I could use a
> `std::function<OptimizationRemarkAnalysis &(Function &)> &` as we do
> in other places with, e.g. the assumption cache, if you guys are happy
> with it.
>

Followed what WholeProgramDevirt does and committed a fix in r311804.
Ideally we should guard this with a compile time flag (as discussed
with Chandler).

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare