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

[David Majnemer via llvm-dev]

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>