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

[Daniel Berlin via llvm-dev]

On Fri, Mar 31, 2017 at 5:02 AM, Michael Kruse <llvmdev at meinersbur.de>
wrote:

> 2017-03-31 13:46 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>:
> >
> >
> > On Fri, Mar 31, 2017 at 4:05 AM, Michael Kruse <llvmdev at meinersbur.de>
> > wrote:
> >>
> >> 2017-03-31 1:16 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>:
> >> > if you transformed
> >> >
> >> > lifetime.start(%p)
> >> > use %p
> >> > lifetime.end(%p)
> >> > into
> >> >
> >> > if (c)
> >> >   lifetime.start(%p)
> >> > use %p
> >> > lifetime.end(%p)
> >> >
> >> > That is *definitely* a bug in polly.
> >> > Stack coloring should be able to handle it if that is the original IR
> >> > but that is definitely not a legal transform of the lifetime.start.
> >>
> >> If it is legal for a frontend to generate it, why is it not legal for
> >> a transformation?
> >
> >
> > Errr.
> > Because, as mentioned, they are not meant to float.
> > They are meant to stay executing under precisely the same conditions the
> > frontend gave them.
> >
> > Also, the set of things for which it is legal for the frontend to do, but
> > not you, is infinite.
> >
> > For example, as mentioned, the frontend may generate:
> >
> > if (c)
> >   memset (a, 0)
> > use(a)
> >
> > But that does not make it legal for you to transform
> >
> > memset(a, 0)
> > use(a)
> >
> > into
> > if (c)
> >   memset(a, 0)
> > use(a)
> >
> > unless you can prove a already had the value 0, or that condition c
> always
> > holds.
>
> Because the semantics are different. And you admit yourself that the
> transformation can be done if the compiler show that it can do the
> transformation if the compiler can show that the value received by
> use(a) will be the same.
>
> How I do understand the current the reference manual for
> llvm.lifetime.start, the semantics of
>
> llvm.lifetime.start(a)
>
> and
>
> if (c)
>   llvm.lifetime.start(a)
>
> are the same if a is not used before that point.


Assuming by before, you mean post-dominance or something, yes, i'd agree.
Yes, *assuming it stays that way* in the IR :)


According to Than
> McIntosh the problem is that StackColoring currently does not
> correctly handle the situation.
>
>
What I would wish for is that the language reference for lifetime
> markers is updated such that it reflects the what StackColoring can
> handle, and that the IR verifier fails when the lifetime markes are
> not well-formed according to that reference. For instance, we can
> define that the end/start marker must (post-)dominate the start/end
> marker.
>
>
I believe, at this point, most of us wish for someting strong: that we
ripped them out by their tendrils, and replaced them withs ometing with
very well defined and useful semantics that are easy to verify.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170331/a326d34d/attachment.html>