[llvm-dev] Well-formed @llvm.lifetime.start and @llvm.lifetime.end intrinsics

[Daniel Berlin via llvm-dev]

On Thu, Mar 30, 2017 at 11:42 PM, David Majnemer <david.majnemer at gmail.com>
wrote:

> Hmm. This doesn't jive with my understanding of how things worked.
>


>
>
I see the lifetime intrinsics as something which _can_ be made conditional
> on arbitrary control flow.
>

That seems very wrong.
The whole purpose of them was because the middle end *does not know* more
than the frontend about the lifetime starting and ending of memory objects
They were not supposed to float.
Much like assume, they were meant to be tethered in place.
Otherwise, they are literally pointless :)
·IE in such a world, we should not be stopping licm, etc, from moving them,
and we should stop letting them block optimization by being marked as
side-effecting.
Whatever happens to them, happens.

Further, if i can make them conditional on arbitrary control flow, i can
cause all the lifetime starts to die, easily, again, something we are
specifically marking them as side-effecting to avoid.

ie

lifetime.start
->
if (dead condition)
 lifetime.start
->
nothing

Now they are all unpaired :)

So maybe you meant something other than arbitrary control flow?
I can probably do worse than this depending on how arbitrary you want (IE
shove them into loops in ways that more things are dead than were before)

I can build a consistent view of them because I also believe the lifetime
> intrinsics can only make sense when they are paired together.
>

That is also not what our langref says.
It does not require pairing:
For example, for lifetime start:
"This intrinsic indicates that before this point in the code, the value of
the memory pointed to by ptr is dead. This means that it is known to never
be used and has an undefined value. A load from the pointer that precedes
this intrinsic can be replaced with 'undef'."

Ignoring "before this point in the code" (which is the argument we have in
the first paragraph), nothing about this requires it be paired.

It would be perfectly reasonable in this definition to have lifetime starts
without ends, for things that begin life in the middle of the function but
extend past it.
Or to say that after a function call, lifetime of memory object has ended
(without it ever starting).

Now, i don't claim these are *good* semantics, but if we want to change
them, we should change them, not just do something different than we
document :)

(in any case, i believe we are rehashing the fact that we all think these
intrinsics are in need of some serious rework to clear up semantics, etc)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170330/d6a0e48f/attachment.html>