llvm dev - Mar 2017 - Well-formed @llvm.lifetime.start and @llvm.lifetime.end intrinsics

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?

Michael

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.

> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170331/71087324/attachment.html>

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. 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.

Michael