[llvm-dev] Jit: use @llvm.lifetime.end to optimize away stores to globals used as temporaries

[Tom Aernoudt via llvm-dev]

> From: Nat! [mailto:nat at mulle-kybernetik.com]
> Tom Aernoudt via llvm-dev schrieb:
> > Hi all,
> >
> > The 'tmp' state variable is only needed during execution of the function
> > 'f'.
> >
> That's what you say, because you called it 'tmp' :), but the compiler
> sees no difference to 'a' or 'b'. As soon as s->tmp would "escape" f()
> the compiler will have to write it.
> 
> I think you may want to keep external state and temporal context separate
> 
> e.g.
> 
> struct State {
>    int a;
>    int b;
> }
> 
> 
> struct Temp {
>    int tmp;
> }
> 
> static void f0( State *s, Temp *t)
> {
>    t->tmp = s->a;
> }
> 
> ...
> 
> void f(State* s)
> 
> {
>     Temp  tmp;
> 
>     f0( s, &tmp);
>     f1( s, &tmp);
> }
> 
> Using @llvm.lifetime.end is IMO a deadend, since this should just
> signify that the alloca is gone.
>

In the real code, the state variables ('tmp',...) do not have trivial constructors. Constructing them as local variables in the function 'f' adds a lot of extra code that may not always be optimized away.
It will also require a lot of change to existing code.

Using the @llvm.lifetime.end intrinsic seems to do exactly what we want to achieve, ie optimize away Store instructions to the 'tmp' variables with no/minimal changes to existing code (only the runtime generated functions 'f' have to be changed to call the @llvm.lifetime.end intrinsics).
Is using the intrinsic on something else as an Alloca allowed? Or is the behavior I see just a side effect of the current implementation and may it break in the future?

Regards,
Tom