<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 26, 2016 at 12:28 PM, Chad Rosier <span dir="ltr"><<a href="mailto:mcrosier@codeaurora.org" target="_blank">mcrosier@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">mcrosier added a comment.<br>
<span class="gmail-"><br>
In <a href="https://reviews.llvm.org/D25969#580042" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D25969#580042</a>, @mcrosier wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D25969#579967" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D25969#579967</a>, @nemanjai wrote:<br>
><br>
> > This caused a failure on all PPC machines I have access to:<br>
> >  AddressSanitizer-powerpc64le-<wbr>linux :: TestCases/use-after-scope-<wbr>loop-bug.cc<br>
><br>
><br>
> Looking now..<br>
<br>
<br>
</span>I believe I've figured out the underlying problem.  In short, LICM is relying on lifetime markers to prevent loads/stores from being moved out of a particular scope.<br>
<br></blockquote><div><br></div><div>Can you file more details on a bug somewhere? This seems pretty broken, but also, without your patch:</div><div><div><div>dannyb@dannyb-macbookpro3 [12:32:05] [~/sources/llvm-clean/lib/Transforms/Scalar] [mssa-batch-renamer-2]</div><div>-> % grep -i lifetime LICM.cpp</div></div><div><br></div></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>From the broken test case:<br>
int main() {<br>
<br>
  // Variable goes in and out of scope.<br>
  for (int i = 0; i < 3; ++i) {<br>
    int x[3] = {i, i, i};<br>
    p = x + i;<br>
  }<br>
  return *p;  // BOOM<br>
<br>
}<br>
<br>
LICM will sink the stores to x[3] after the loop, which is obviously incorrect. </blockquote><div><br></div><div>I don't see why?</div><div>First, let's ignore the c-semantics, it's broken as-written in c, since the variable is dead whether you sink the stores or not.  (ASAN is a separate issue and should disable moving past lifetime markers or something)</div><div><br></div><div>Assuming p is a pointer, sinking the stores to before *p is just as fine as it is now, as long as you move the lifetime start and end markers to go with it (or drop them).</div><div><br></div><div>I presume the alloca does not occur in the loop, only the lifetime start and end.</div><div>In particular, you should be able to simply drop all lifetime start and end, and get the same result.</div><div><br></div><div>IE lifetime start and end do not serve as a dependence here, only metadata. If the only thing preventing LICM is the lifetime markers, that's very wrong since they are non-guaranteed metadata</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I've reverted the change in r285227.  Sorry for the breakage.<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br></div></div></blockquote><div>You should be able to fix this simply by either</div><div>1. dropping the lifetime markers (non-ideal) of things you sink.</div><div>or</div><div>2.  extending the lifetime markers appropriately.</div><div><br></div><div>The algorithm for that is that when you eliminate or sink things past them, you move the end to wherever the lowest point you sunk to is.</div><div>You move starts to a block that post-dominates both the new end and the old end.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D25969" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D25969</a><br>
<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>