<div dir="ltr">Hmm. This doesn't jive with my understanding of how things worked.<div><br></div><div>I see the lifetime intrinsics as something which _can_ be made conditional on arbitrary control flow. I can build a consistent view of them because I also believe the lifetime intrinsics can only make sense when they are paired together.</div><div><br></div><div>Another way of thinking about it is that a store of undef can be used to make an earlier store dead but it can also be safely removed or even be made conditional on arbitrary control flow. There is no non-UB way of detecting that such a store remains or was eliminated.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 31, 2017 at 3:38 AM, Daniel Berlin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sure, and you definitely can't transform an unconditional store to a conditional one unless the uses are guarded by the same condition, or you can prove it already had that value (in which case, the memset would also be dead) :)<div><br></div><div>ie</div><div>memset(a, 0)</div><div>use a</div><div><br></div><div>can't be transformed to</div><div>if (c)</div><div>  memset(a, 0)</div><div>use a</div><div><br></div><div>So again, if polly is making a lifetime.start conditional when the use is not conditional, that's a bug in polly, regardless of the bug in stack coloring's ability to handle it.</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 30, 2017 at 4:21 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It's useful to think about lifetime.start/end as being equivalent to a memset of undef. They effectively clobber what was there and reinitialize it with "nothing". If you transform lifetime.start in a way that would be incorrect if it were storing undef, then that transform is incorrect.</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-7025130836985986997h5">On Thu, Mar 30, 2017 at 4:16 PM, Daniel Berlin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-7025130836985986997h5"><div dir="ltr">Interesting.<div>They are marked this way specifically to prevent things from moving them this way, and it blocks other optimization. So if we are ignoring it to move them, it seems either "they shouldn't be moved", or "we shouldn't  mark them" :P</div><div><br></div><div><br></div><div>Thinking harder about this.</div><div>if you transformed</div><div><br></div><div>lifetime.start(%p)</div><div>use %p</div><div>lifetime.end(%p)</div><div>into</div><div><br></div><div>if (c)</div><div>  lifetime.start(%p)</div><div><div>use %p</div><div>lifetime.end(%p)</div></div><div><br></div><div>That is *definitely* a bug in polly.</div><div>Stack coloring should be able to handle it if that is the original IR but that is definitely not a legal transform of the lifetime.start.</div><div><br></div><div><br></div></div><div class="m_-7025130836985986997m_1936103998040182749HOEnZb"><div class="m_-7025130836985986997m_1936103998040182749h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 30, 2017 at 4:09 PM, Michael Kruse <span dir="ltr"><<a href="mailto:llvmdev@meinersbur.de" target="_blank">llvmdev@meinersbur.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>2017-03-31 0:54 GMT+02:00 Daniel Berlin <<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</a>>:<br>
> I'm curious, btw, what made it think the above is legal.<br>
> The intrinsics are marked as touching memory, having side effects, etc.<br>
<br>
</span>The precedes my involvement with Polly.<br>
<br>
Polly has a list of intrinsics that can be safely ignored, e.g.<br>
llvm.dbg.value/llvm.gbg.declar<wbr>e. The lifetime markers are also in this<br>
list. Ignored intrinsic are ... well ... ignored when generating the<br>
optimized code.<br>
<span class="m_-7025130836985986997m_1936103998040182749m_-1417555147059679645HOEnZb"><font color="#888888"><br>
Michael<br>
</font></span></blockquote></div><br></div>
</div></div><br></div></div><span>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>