<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/05/2014 01:44 PM, Nick Lewycky
wrote:<br>
</div>
<blockquote
cite="mid:CADbEz-h4ksVwgg3m6p-nxV=aK3KfBDYzGzeG8AkrCakHKvjrxg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 5 November 2014 13:37, Philip
Reames <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class=""><br>
On 11/05/2014 12:59 PM, Nick Lewycky wrote:<br>
</span><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
</span>
In my previous response, I'd missed this bit of text:<span
class=""><br>
"What does it mean to have start/end/start/end?"<br>
<br>
</span>
You're right, this is ill defined. This is an area which
needs clarified.<br>
<br>
I'm still confused by the rest of your response. In
particular, I don't see the text which inspires:<span
class=""><br>
"Can you use an alloca normally, then lifetime.start
it?"<br>
<br>
</span>
The text doesn't talk about uses. It talks about values
of *memory locations*.</blockquote>
<div><br>
</div>
<div>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?</div>
</div>
</div>
</div>
</blockquote>
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. <br>
<br>
(Keep in mind, this is my interpretation of what the rules "should
be". If we decide on this interpretation, we should clarify the
docs.) <br>
<br>
<br>
<blockquote
cite="mid:CADbEz-h4ksVwgg3m6p-nxV=aK3KfBDYzGzeG8AkrCakHKvjrxg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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.</div>
</div>
</div>
</div>
</blockquote>
This is exactly why we shouldn't have the implicit lifetime start.
<br>
<br>
Philip<br>
<br>
</body>
</html>