[llvm-commits] [llvm] r151429 - in /llvm/trunk: include/llvm/Transforms/IPO.h include/llvm/Transforms/IPO/InlinerPass.h include/llvm/Transforms/Utils/Cloning.h lib/Transforms/IPO/InlineAlways.cpp lib/Transforms/IPO/InlineSimple.cpp lib/Transforms/IPO/Inliner.cpp lib/Transforms/Utils/InlineFunction.cpp

[Chad Rosier]

On Feb 27, 2012, at 12:08 AM, Duncan Sands <baldrick at free.fr> wrote:

> Hi Chad,
> 
>>>>>> Add support for disabling llvm.lifetime intrinsics in the AlwaysInliner. These
>>>>>> are optimization hints, but at -O0 we're not optimizing.  This becomes a problem
>>>>>> when the alwaysinline attribute is abused.
>>>>>> rdar://10921594
>>>>> 
>>>>> can you please explain some more for those of us who can't access rdar.  Why is
>>>>> it a problem, and what alwaysinline abuse do you have in mind?
>>>> 
>>>> At -O0 the AlwaysInliner pass is run to honor the always_inline attribute.  By default the @llvm.lifetime_start and @llvm.lifetime_end intrinsics were being emitted.  These are compiler hints and at -O0 they're never used and thus should not be emitted.  The particular test case I came across was compiling in 283s at -O0 (fast, huh).  Now it compiles in 1.35s at -O0.
>>> 
>>> thanks for the explanation.  Why was it taking so long?  Just the insertion of
>>> these intrinsics or something else?  It seems strange to me that compilation
>>> should be slowed down so much - maybe it is a sign that something else is wrong,
>>> some kind of inefficient handling of these intrinsics?
>> 
>> Basically, the target-independent and target-dependent fast-isel implementations were unable to handle these intrinsics and were falling back to the selection DAG selector.  Eric fixed the target-independent selector by ignoring these intrinsics (see: http://llvm.org/viewvc/llvm-project?view=rev&revision=150848).  However, Eric and I both agree that this was an incomplete fix, which is what r151429/151430 was all about.
>> 
>> The reason this was such a problem is because of how fast-isel handles calls.  In most instanced when fast-isel fails to select an instruction it bails and falls back to the selection DAG selector for the remainder of a basic block.  Call are treated differently, however.  Failures by fast-isel to select a call fall back to the selection DAG for the call only and then return to fast-isel to finish selecting the remainder of the block.  This is due to historical reasons, which Dan Gohman could probably best explain.  This context switching between fast-isel and selection DAG isel is most likely the culprit.  You also have to keep in mind that this was a very extreme case.  Of the 250K lines of IR 50K were llvm.lifetime intrinsics (at -O0!!!).  IMHO I don't think there's any fundamental issue with how fast-isel is working.
> 
> thanks for the explanation.  Can't the SelectionDAGBuilder just lower these
> intrinsics to nothing/undef at -O0?

That may be one possible solution, but I don't thing it would be better then just not omitting the markers at -O0.

 Chad

> Ciao, Duncan.