[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 26, 2012, at 12:22 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.

 Chad

> Ciao, Duncan.
> 
>  By abuse I mean the developer thinks they're smarted then the compiler, so they mark everything with the always_inline attribute.  I'm not saying this is a common problem, but regardless these intrinsics are useless at -O0.
>> 
>>> You also forgot to add a testcase.
>> 
>> Yes, you're right.  I will add one soon.  Thanks for keeping me honest, Duncan.
>> 
>>  Chad
>> 
>>> 
>>> Ciao, Duncan.
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> 
>