[llvm-commits] [llvm] r167821 - in /llvm/trunk: lib/Transforms/Utils/InlineFunction.cpp test/Transforms/Inline/lifetime-no-datalayout.ll test/Transforms/Inline/lifetime.ll

[Duncan Sands]

Hi Nick,

On 13/11/12 22:11, Nick Lewycky wrote:
> Duncan Sands wrote:
>> Hi Alexey,
>>
>>> Figure out <size> argument of llvm.lifetime intrinsics at the moment
>>> they are created (during function inlining)
>>
>> wouldn't it be better to do this in instcombine?
>
> Whoever creates it in the first place already has a handle on it and should do
> the best job they can.

GCC has lifetime information for local variables, and dragonegg outputs this
using lifetime intrinsics.  For variable sized objects it can't do any better
than to output a size of "-1".

  Same reason passes run SimplifyInstruction on
> instructions they just emitted, or PromoteMemToReg on allocas they just emitted.
> There's no reason to create the wrong thing and then have that pass through some
> number of passes before it gets corrected.
>
> However, I agree that we should consider adding similar logic to instcombine, if
> that's also useful. Is it useful? I'm sure that the inliner isn't introducing
> lifetime intrinsics with sizes it can't solve itself, but if we're going to
> teach clang to emit them then certainly we will want to solve their sizes in
> instcombine too.

Exactly: it is very reasonable for front-ends to output lifetime intrinsics
directly (and dragonegg does already).

Ciao, Duncan.