<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 31, 2017 at 5:02 AM, 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"><div class="HOEnZb"><div class="h5">2017-03-31 13:46 GMT+02:00 Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>>:<br>
><br>
><br>
> On Fri, Mar 31, 2017 at 4:05 AM, Michael Kruse <<a href="mailto:llvmdev@meinersbur.de">llvmdev@meinersbur.de</a>><br>
> wrote:<br>
>><br>
>> 2017-03-31 1:16 GMT+02:00 Daniel Berlin <<a href="mailto:dberlin@dberlin.org">dberlin@dberlin.org</a>>:<br>
>> > if you transformed<br>
>> ><br>
>> > lifetime.start(%p)<br>
>> > use %p<br>
>> > lifetime.end(%p)<br>
>> > into<br>
>> ><br>
>> > if (c)<br>
>> >   lifetime.start(%p)<br>
>> > use %p<br>
>> > lifetime.end(%p)<br>
>> ><br>
>> > That is *definitely* a bug in polly.<br>
>> > Stack coloring should be able to handle it if that is the original IR<br>
>> > but that is definitely not a legal transform of the lifetime.start.<br>
>><br>
>> If it is legal for a frontend to generate it, why is it not legal for<br>
>> a transformation?<br>
><br>
><br>
> Errr.<br>
> Because, as mentioned, they are not meant to float.<br>
> They are meant to stay executing under precisely the same conditions the<br>
> frontend gave them.<br>
><br>
> Also, the set of things for which it is legal for the frontend to do, but<br>
> not you, is infinite.<br>
><br>
> For example, as mentioned, the frontend may generate:<br>
><br>
> if (c)<br>
>   memset (a, 0)<br>
> use(a)<br>
><br>
> But that does not make it legal for you to transform<br>
><br>
> memset(a, 0)<br>
> use(a)<br>
><br>
> into<br>
> if (c)<br>
>   memset(a, 0)<br>
> use(a)<br>
><br>
> unless you can prove a already had the value 0, or that condition c always<br>
> holds.<br>
<br>
</div></div>Because the semantics are different. And you admit yourself that the<br>
transformation can be done if the compiler show that it can do the<br>
transformation if the compiler can show that the value received by<br>
use(a) will be the same.<br>
<br>
How I do understand the current the reference manual for<br>
llvm.lifetime.start, the semantics of<br>
<br>
llvm.lifetime.start(a)<br>
<br>
and<br>
<br>
if (c)<br>
  llvm.lifetime.start(a)<br>
<br>
are the same if a is not used before that point.</blockquote><div><br></div><div>Assuming by before, you mean post-dominance or something, yes, i'd agree.</div><div>Yes, *assuming it stays that way* in the IR :)<br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">According to Than<br>
McIntosh the problem is that StackColoring currently does not<br>
correctly handle the situation.<br>
<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What I would wish for is that the language reference for lifetime<br>
markers is updated such that it reflects the what StackColoring can<br>
handle, and that the IR verifier fails when the lifetime markes are<br>
not well-formed according to that reference. For instance, we can<br>
define that the end/start marker must (post-)dominate the start/end<br>
marker.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>I believe, at this point, most of us wish for someting strong: that we ripped them out by their tendrils, and replaced them withs ometing with very well defined and useful semantics that are easy to verify.</div><div><br></div></div></div></div>