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

It's useful to think about lifetime.start/end as being equivalent to a
memset of undef. They effectively clobber what was there and reinitialize
it with "nothing". If you transform lifetime.start in a way that would
be
incorrect if it were storing undef, then that transform is incorrect.

On Thu, Mar 30, 2017 at 4:16 PM, Daniel Berlin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Interesting.
> They are marked this way specifically to prevent things from moving them
> this way, and it blocks other optimization. So if we are ignoring it to
> move them, it seems either "they shouldn't be moved", or
"we shouldn't
>  mark them" :P
>
>
> Thinking harder about this.
> 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.
>
>
>
> On Thu, Mar 30, 2017 at 4:09 PM, Michael Kruse <llvmdev at
meinersbur.de>
> wrote:
>
>> 2017-03-31 0:54 GMT+02:00 Daniel Berlin <dberlin at dberlin.org>:
>> > I'm curious, btw, what made it think the above is legal.
>> > The intrinsics are marked as touching memory, having side effects,
etc.
>>
>> The precedes my involvement with Polly.
>>
>> Polly has a list of intrinsics that can be safely ignored, e.g.
>> llvm.dbg.value/llvm.gbg.declare. The lifetime markers are also in this
>> list. Ignored intrinsic are ... well ... ignored when generating the
>> optimized code.
>>
>> Michael
>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170330/e4cc9c84/attachment.html>

Sure, and you definitely can't transform an unconditional store to a
conditional one unless the uses are guarded by the same condition, or you
can prove it already had that value (in which case, the memset would also
be dead) :)

ie
memset(a, 0)
use a

can't be transformed to
if (c)
  memset(a, 0)
use a

So again, if polly is making a lifetime.start conditional when the use is
not conditional, that's a bug in polly, regardless of the bug in stack
coloring's ability to handle it.



On Thu, Mar 30, 2017 at 4:21 PM, Reid Kleckner <rnk at google.com> wrote:
> It's useful to think about lifetime.start/end as being equivalent to a
> memset of undef. They effectively clobber what was there and reinitialize
> it with "nothing". If you transform lifetime.start in a way that
would be
> incorrect if it were storing undef, then that transform is incorrect.
>
> On Thu, Mar 30, 2017 at 4:16 PM, Daniel Berlin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Interesting.
>> They are marked this way specifically to prevent things from moving
them
>> this way, and it blocks other optimization. So if we are ignoring it to
>> move them, it seems either "they shouldn't be moved", or
"we shouldn't
>>  mark them" :P
>>
>>
>> Thinking harder about this.
>> 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.
>>
>>
>>
>> On Thu, Mar 30, 2017 at 4:09 PM, Michael Kruse <llvmdev at
meinersbur.de>
>> wrote:
>>
>>> 2017-03-31 0:54 GMT+02:00 Daniel Berlin <dberlin at
dberlin.org>:
>>> > I'm curious, btw, what made it think the above is legal.
>>> > The intrinsics are marked as touching memory, having side
effects, etc.
>>>
>>> The precedes my involvement with Polly.
>>>
>>> Polly has a list of intrinsics that can be safely ignored, e.g.
>>> llvm.dbg.value/llvm.gbg.declare. The lifetime markers are also in
this
>>> list. Ignored intrinsic are ... well ... ignored when generating
the
>>> optimized code.
>>>
>>> Michael
>>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170330/14f2c43f/attachment.html>

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. I can build a consistent view of them because I
also believe the lifetime intrinsics can only make sense when they are
paired together.

Another way of thinking about it is that a store of undef can be used to
make an earlier store dead but it can also be safely removed or even be
made conditional on arbitrary control flow. There is no non-UB way of
detecting that such a store remains or was eliminated.

On Fri, Mar 31, 2017 at 3:38 AM, Daniel Berlin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Sure, and you definitely can't transform an unconditional store to a
> conditional one unless the uses are guarded by the same condition, or you
> can prove it already had that value (in which case, the memset would also
> be dead) :)
>
> ie
> memset(a, 0)
> use a
>
> can't be transformed to
> if (c)
>   memset(a, 0)
> use a
>
> So again, if polly is making a lifetime.start conditional when the use is
> not conditional, that's a bug in polly, regardless of the bug in stack
> coloring's ability to handle it.
>
>
>
> On Thu, Mar 30, 2017 at 4:21 PM, Reid Kleckner <rnk at google.com>
wrote:
>
>> It's useful to think about lifetime.start/end as being equivalent
to a
>> memset of undef. They effectively clobber what was there and
reinitialize
>> it with "nothing". If you transform lifetime.start in a way
that would be
>> incorrect if it were storing undef, then that transform is incorrect.
>>
>> On Thu, Mar 30, 2017 at 4:16 PM, Daniel Berlin via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Interesting.
>>> They are marked this way specifically to prevent things from moving
them
>>> this way, and it blocks other optimization. So if we are ignoring
it to
>>> move them, it seems either "they shouldn't be moved",
or "we shouldn't
>>>  mark them" :P
>>>
>>>
>>> Thinking harder about this.
>>> 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.
>>>
>>>
>>>
>>> On Thu, Mar 30, 2017 at 4:09 PM, Michael Kruse <llvmdev at
meinersbur.de>
>>> wrote:
>>>
>>>> 2017-03-31 0:54 GMT+02:00 Daniel Berlin <dberlin at
dberlin.org>:
>>>> > I'm curious, btw, what made it think the above is
legal.
>>>> > The intrinsics are marked as touching memory, having side
effects,
>>>> etc.
>>>>
>>>> The precedes my involvement with Polly.
>>>>
>>>> Polly has a list of intrinsics that can be safely ignored, e.g.
>>>> llvm.dbg.value/llvm.gbg.declare. The lifetime markers are also
in this
>>>> list. Ignored intrinsic are ... well ... ignored when
generating the
>>>> optimized code.
>>>>
>>>> Michael
>>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170331/6da4a858/attachment-0001.html>

2017-03-31 3:38 GMT+02:00 Daniel Berlin <dberlin at
dberlin.org>:
> Sure, and you definitely can't transform an unconditional store to a
> conditional one unless the uses are guarded by the same condition, or you
> can prove it already had that value (in which case, the memset would also
be
> dead) :)
>
> ie
> memset(a, 0)
> use a
>
> can't be transformed to
> if (c)
>   memset(a, 0)
> use a
>
> So again, if polly is making a lifetime.start conditional when the use is
> not conditional, that's a bug in polly, regardless of the bug in stack
> coloring's ability to handle it.
InstCombine transforms memset(a,1) to a single StoreInst, but keeps
the memset if the size argument is zero. A StoreInst can be optimized
away, e.g. by DeadStoreElimination. I wonder, are the semantics of
memset(a, 0) different than "do nothing"?

Where is the chain of transformations

memset(&a, '0', sizeof a);
if (c)
  a = 1;

=>

if (c) {
  memset(&a, '0', sizeof a);
  a = 1;
} else
  memset(&a, '0', sizeof a);

=>

if (c) {
  memset(&a, '0', sizeof a);
  a = 1;
} else
  memset(&a, '0', sizeof a);

=>

if (c) {
  a = 0;
  a = 1;
} else
  memset(&a, '0', sizeof a);

=>

if (c)
  a = 1;
else
  memset(&a, '0', sizeof a);

=>
if (c)
  a = 0;
if (!c)
  memset(&a, '0', sizeof a);


not legal?

Michael