[LLVMdev] lifetime.start/end clarification

[Nick Lewycky]

On 5 November 2014 13:37, Philip Reames <listmail at philipreames.com> wrote:

>
> On 11/05/2014 12:59 PM, Nick Lewycky wrote:
>
>> The LangRef definition looks like that plus some special rules about how
>> *all* uses before the start are dead. *The* start? What about multiple
>> starts? What does it mean to have start/end/start/end? Can you use an
>> alloca normally, then lifetime.start it? According to langref, no, *all*
>> uses before the start may be nuked. It's a weird rule, but it's intended to
>> support the use case of stack slot colouring, where your starts and ends
>> are paired and tightly wrap the point where the variable is live.
>>
> In my previous response, I'd missed this bit of text:
> "What does it mean to have start/end/start/end?"
>
> You're right, this is ill defined.  This is an area which needs clarified.
>
> I'm still confused by the rest of your response.  In particular, I don't
> see the text which inspires:
> "Can you use an alloca normally, then lifetime.start it?"
>
> The text doesn't talk about uses.  It talks about values of *memory
> locations*.


Sorry, I was unclear. I meant, suppose you alloca, then store to it, then
load it, then call lifetime.start. The use of lifetime.start goes *back in
time* and states that the memory has been undef up until that point. The
load can be optimized away into undef. The store value can be optimized
away into undef? What is going on?

A simple fix is to define that all alloca's perform lifetime.start
implicitly, but if that's so, then what does alloca+store+lifetime.start
do? The intention of lifetime.start was to provide a way to eliminate a
dead store before the lifetime.start, but now you can't because the memory
was live at the time due to the implicit lifetime.start in the alloca.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141105/2518ad88/attachment.html>