[LLVMdev] lifetime.start/end clarification

[Philip Reames]

On 11/05/2014 12:59 PM, Nick Lewycky wrote:
> On 5 November 2014 12:48, Hal Finkel <hfinkel at anl.gov 
> <mailto:hfinkel at anl.gov>> wrote:
>
>     ----- Original Message -----
>     > From: "Nick Lewycky" <nlewycky at google.com
>     <mailto:nlewycky at google.com>>
>     > To: "Hal Finkel" <hfinkel at anl.gov <mailto:hfinkel at anl.gov>>
>     > Cc: "Reid Kleckner" <rnk at google.com <mailto:rnk at google.com>>,
>     "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu
>     <mailto:llvmdev at cs.uiuc.edu>>
>     > Sent: Wednesday, November 5, 2014 2:39:38 PM
>     > Subject: Re: [LLVMdev] lifetime.start/end clarification
>     >
>     > On 5 November 2014 11:51, Hal Finkel < hfinkel at anl.gov
>     <mailto:hfinkel at anl.gov> > wrote:
>     > > and both should be remodeled to just mean "store of
>     > > undef bytes to this memory".
>     >
>     > This is a bad idea. Stores of undef bytes can be removed if we can
>     > prove that the address is dereferenceable. And if they can't be
>     > removed, then they have side effects that can't ever be removed.
>     > Please don't do that.
>     >
>     > I think the idea is to define them with the semantics of storing
>     > undef bytes, but keep them implemented as intrinsic function calls,
>     > so that the optimizer does not simply delete them. It's a way of
>     > communicating that these are deliberate and valuable stores to
>     > undef, as opposed to stores of SSA values that were later found to
>     > be undef.
>
>     I did not get that impression, and if that is what was proposed, I
>     don't see how that differs, in practice, from what we have now.
>
>
> 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.
Er, what text are you referring to?  I don't see anything like this in 
the intrinsics definition section.  Could you quote exactly what you're 
referencing?

This is the text I see for lifetime.start:
"This intrinsic indicates that before this point in the code, the value 
of the memory pointed to by ptr is dead. This means that it is known to 
never be used and has an undefined value. A load from the pointer that 
precedes this intrinsic can be replaced with 'undef'."
>
> If you remove that oddity, lifetime.start and lifetime.end become 
> semantically equivalent and both just mean "store undef there" and 
> become straight-forward to reason about, though harder to use for 
> stack slot colouring (it becomes a bidirectional data flow problem, 
> which is hard on compile time). At this stage, I think the tradeoff is 
> worthwhile.
Specifically what are you proposing?  I have yet to see a clearly worded 
proposal here and it seems like different folks have different mental 
models.  Could you spell out your desired semantics?

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141105/8b2c71d9/attachment.html>