<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 10:54 AM, Reid Kleckner
wrote:<br>
</div>
<blockquote
cite="mid:CACs=tyJX99ziYJL3TkeAzWKAogZc=Th--b+ZuYBbSwjKZP6XUw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">This seems fine to
me. The optimizer can (soundly) conclude that %p is
dead after the "lifetime.end" (for the two
instructions), and dead before the "lifetime.start" (for
the *single* instruction in that basic block, *not* for
the previous BB). This seems like the proper result for
this example, am I missing something?</div>
</blockquote>
<div><br>
</div>
<div>What if I put that in a loop, unroll it once, and prove
that the lifetime.start is unreachable? We would end up
with IR like:</div>
<div><br>
</div>
<div>loop:</div>
<div> ... use %p</div>
<div> call void @lifetime.end( %p )</div>
<div>
<div> ... use %p</div>
<div> call void @lifetime.end( %p )</div>
</div>
<div> br i1 %c, label %loop, label %exit</div>
<div><br>
</div>
<div>Are the second uses of %p uses of dead memory?</div>
</div>
</div>
</div>
</blockquote>
It's hard to discuss this without being specific about the starting
IR and transforms. My general response is that either a) such a
transform wouldn't be valid or b) the behaviour of the original
program was undefined. <br>
<br>
In the particular final IR result you gave, the second use of %p
would be dead. Moreover, if the optimizer can prove this loop
iterates at least once, *all access* to %p in the loop is dead.
This is exactly the semantics you want.<br>
<blockquote
cite="mid:CACs=tyJX99ziYJL3TkeAzWKAogZc=Th--b+ZuYBbSwjKZP6XUw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>We have similar issues if the optimizer somehow removes
the lifetime end and keeps the start:</div>
<div><br>
</div>
<div>
<div>loop:</div>
<div> call void @lifetime.start( %p )<br>
</div>
<div> ... use %p</div>
<div> call void @lifetime.start( %p )<br>
</div>
<div>
<div> ... use %p</div>
</div>
<div> br i1 %c, label %loop, label %exit</div>
</div>
</div>
</div>
</div>
</blockquote>
But we can't just drop arbitrary calls. Doing so is unsound. <br>
<blockquote
cite="mid:CACs=tyJX99ziYJL3TkeAzWKAogZc=Th--b+ZuYBbSwjKZP6XUw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>For this reason, it has been suggested that these
intrinsics are horribly broken, and both should be
remodeled to just mean "store of undef bytes to this
memory". If "use %p" is a load, for example, in both cases
we can safely say it returns undef, because it's a
use-after-scope.</div>
</div>
</div>
</div>
</blockquote>
I'm not actually intrinsically opposed to just an alternative. I
would like to see a concrete example justifying the proposal
though. Nothing said in this thread to date warrants redefining
these intrinsics. <br>
<br>
Worth stating explicitly: your proposed semantics are strictly *less
powerful* than the current ones. They may be "simpler", but you
loose optimization possibilities. <br>
<blockquote
cite="mid:CACs=tyJX99ziYJL3TkeAzWKAogZc=Th--b+ZuYBbSwjKZP6XUw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>I think coming up with a new representation with
simpler semantics is the way to go. One allocation or
lifetime start, and one deallocation and end.</div>
</div>
</div>
</div>
</blockquote>
At least so far, I disagree. I am open to being convinced though.
:)<br>
<blockquote
cite="mid:CACs=tyJX99ziYJL3TkeAzWKAogZc=Th--b+ZuYBbSwjKZP6XUw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Implementing this in Clang will be tricky, though.
Clang's IRGen is supposed to be a dumb AST walk, but it
has already strayed from that path. Needs more thought...</div>
</div>
</div>
</div>
</blockquote>
Do you have motivating cases other than a goto into a scoped
region? That seems like a fairly straight forward "special case".
How far would you get by special casing a few cases that matter and
leaving the general problem unsolved? At worst, you're missing an
optimization here. <br>
<br>
</body>
</html>