<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="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="h5">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="h5"><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_1936103998040182749HOEnZb"><div class="m_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_1936103998040182749m_-1417555147059679645HOEnZb"><font color="#888888"><br>
Michael<br>
</font></span></blockquote></div><br></div>
</div></div><br></div></div><span class="">______________________________<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>