[LLVMdev] lifetime.start/end clarification

[Philip Reames]

On 11/05/2014 01:44 PM, Nick Lewycky wrote:
> On 5 November 2014 13:37, Philip Reames <listmail at philipreames.com 
> <mailto: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?
With this example, you'd written code which is ill defined.  The 
optimizer is welcome to simplify drop the store.  I would even argue 
that it could assume that the store "couldn't happen" and convert it to 
an unreachable.  While this might not be "friendly", it's probably a 
good thing for optimization effectiveness.

(Keep in mind, this is my interpretation of what the rules "should be".  
If we decide on this interpretation, we should clarify the docs.)


> 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.
This is exactly why we shouldn't have the implicit lifetime start.

Philip

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