<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/05/2014 12:59 PM, Nick Lewycky
wrote:<br>
</div>
<blockquote
cite="mid:CADbEz-jv_M5i5uBrDLUfM4ZH=LsSz467tqPtdjJty7zFOPtCLA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On 5 November 2014 12:48, Hal Finkel
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span>-----
Original Message -----<br>
> From: "Nick Lewycky" <<a moz-do-not-send="true"
href="mailto:nlewycky@google.com" target="_blank">nlewycky@google.com</a>><br>
> To: "Hal Finkel" <<a moz-do-not-send="true"
href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br>
</span>
<div>
<div>> Cc: "Reid Kleckner" <<a
moz-do-not-send="true" href="mailto:rnk@google.com"
target="_blank">rnk@google.com</a>>, "LLVM
Developers Mailing List" <<a moz-do-not-send="true"
href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>><br>
> Sent: Wednesday, November 5, 2014 2:39:38 PM<br>
> Subject: Re: [LLVMdev] lifetime.start/end
clarification<br>
><br>
> On 5 November 2014 11:51, Hal Finkel < <a
moz-do-not-send="true" href="mailto:hfinkel@anl.gov"
target="_blank">hfinkel@anl.gov</a> > wrote:<br>
</div>
</div>
<span>
> > and both should be remodeled to just mean
"store of<br>
> > undef bytes to this memory".<br>
><br>
> This is a bad idea. Stores of undef bytes can be
removed if we can<br>
> prove that the address is dereferenceable. And if
they can't be<br>
> removed, then they have side effects that can't
ever be removed.<br>
> Please don't do that.<br>
><br>
> I think the idea is to define them with the
semantics of storing<br>
> undef bytes, but keep them implemented as intrinsic
function calls,<br>
> so that the optimizer does not simply delete them.
It's a way of<br>
> communicating that these are deliberate and
valuable stores to<br>
> undef, as opposed to stores of SSA values that were
later found to<br>
> be undef.<br>
<br>
</span>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.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
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?<br>
<br>
This is the text I see for lifetime.start:<br>
"This intrinsic indicates that before this point in the code, the
value
of the memory pointed to by <tt class="docutils literal"><span
class="pre">ptr</span></tt> 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 <tt
class="docutils literal"><span class="pre">'undef'</span></tt>."
<blockquote
cite="mid:CADbEz-jv_M5i5uBrDLUfM4ZH=LsSz467tqPtdjJty7zFOPtCLA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
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?<br>
<br>
Philip<br>
</body>
</html>