<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 November 2014 11:51, Hal Finkel <span dir="ltr"><<a 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 class="">----- Original Message -----<br>
> From: "Reid Kleckner" <<a href="mailto:rnk@google.com">rnk@google.com</a>><br>
> To: "Philip Reames" <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>><br>
> Cc: "LLVM Developers Mailing List" <<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>><br>
> Sent: Wednesday, November 5, 2014 12:54:30 PM<br>
> Subject: Re: [LLVMdev] lifetime.start/end clarification<br>
><br>
</span><span class="">> This seems fine to me. The optimizer can (soundly) conclude that %p<br>
> is dead after the "lifetime.end" (for the two instructions), and<br>
> dead before the "lifetime.start" (for the *single* instruction in<br>
> that basic block, *not* for the previous BB). This seems like the<br>
> proper result for this example, am I missing something?<br>
><br>
><br>
> What if I put that in a loop, unroll it once, and prove that the<br>
> lifetime.start is unreachable? We would end up with IR like:<br>
><br>
><br>
> loop:<br>
> ... use %p<br>
> call void @lifetime.end( %p )<br>
><br>
> ... use %p<br>
> call void @lifetime.end( %p )<br>
> br i1 %c, label %loop, label %exit<br>
><br>
><br>
> Are the second uses of %p uses of dead memory?<br>
><br>
><br>
> We have similar issues if the optimizer somehow removes the lifetime<br>
> end and keeps the start:<br>
><br>
><br>
><br>
> loop:<br>
> call void @lifetime.start( %p )<br>
><br>
> ... use %p<br>
> call void @lifetime.start( %p )<br>
><br>
><br>
> ... use %p<br>
> br i1 %c, label %loop, label %exit<br>
><br>
><br>
> For this reason, it has been suggested that these intrinsics are<br>
> horribly broken,<br>
<br>
</span>I disagree, these just seem like bugs. lifetime_start are marked as IntrReadWriteArgMem, but this is not really sufficient to prevent their removal should the memory be subsequently unused. Plus there are other places that just delete the lifetime intrinsics, like this in lib/Transforms/Scalar/SROA.cpp:<br>
<br>
      // FIXME: Currently the SSAUpdater infrastructure doesn't reason about<br>
      // lifetime intrinsics and so we strip them (and the bitcasts+GEPs<br>
      // leading to them) here. Eventually it should use them to optimize the<br>
      // scalar values produced.<br>
      if (IntrinsicInst *II = dyn_cast<IntrinsicInst>(I)) {<br>
        assert(II->getIntrinsicID() == Intrinsic::lifetime_start ||<br>
               II->getIntrinsicID() == Intrinsic::lifetime_end);<br>
        II->eraseFromParent();<br>
        continue;<br>
      }<br>
<br>
we need to go through the various places that might delete these intrinsics and fix them. The same will be true with any other mechanism.<br></blockquote><div><br></div><div>It removes them because it does (or will) remove the associated alloca anyways as part of turning loads and stores into SSA. There's no need for lifetime intrinsic equivalents on SSA given that we have use-lists and tools like the dominator tree.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> and both should be remodeled to just mean "store of<br>
> undef bytes to this memory".<br>
<br>
</span>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.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
 -Hal<br>
</font></span><span class="im HOEnZb"><br>
> If "use %p" is a load, for example, in<br>
> both cases we can safely say it returns undef, because it's a<br>
> use-after-scope.<br>
><br>
><br>
> I think coming up with a new representation with simpler semantics is<br>
> the way to go. One allocation or lifetime start, and one<br>
> deallocation and end.<br>
><br>
><br>
> Implementing this in Clang will be tricky, though. Clang's IRGen is<br>
> supposed to be a dumb AST walk, but it has already strayed from that<br>
> path. Needs more thought...<br>
</span><span class="im HOEnZb">> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
</span><span class="im HOEnZb">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div></div>