[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

[Eric Christopher]

On Feb 27, 2012, at 9:49 AM, Chad Rosier <mcrosier at apple.com> wrote:

> 
> 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.

Agreed. fast-isel does just ignore them now, but not emitting them is not emitting a bunch of instructions.

-eric