[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

[Duncan Sands]

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?

Ciao, Duncan.