<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi all,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default"><div class="gmail_default">Just to clarify: the code I'm seeing in the stack coloring dumps is a little different from what is being discussed in previous spots in this thread. The example that Michael cited earlier on was</div><div class="gmail_default"><br></div><div class="gmail_default">    if (c) {</div><div class="gmail_default">      llvm.lifetime.start(&var)</div><div class="gmail_default">    }</div><div class="gmail_default">    [...]</div><div class="gmail_default">    llvm.lifetime.end(&var)</div><div class="gmail_default"><br></div><div class="gmail_default">however what I'm seeing is:</div><div class="gmail_default"><br></div><div class="gmail_default">    entry block:</div><div class="gmail_default">    [...]</div><div class="gmail_default">    if (c) {           // conditional branch terminating entry block</div><div class="gmail_default">      llvm.lifetime.start(&var)</div><div class="gmail_default">      [...]</div><div class="gmail_default">      exit(..);        // this is a no-return-call</div><div class="gmail_default">    }</div><div class="gmail_default">    [...]</div><div class="gmail_default">    llvm.lifetime.end(&var)</div><div class="gmail_default"><br></div><div class="gmail_default">In the first example there is a path from the lifetime start op to uses of the variable. In the second example (which is what I see when I look at the stack coloring dumps) there is no such path.</div><div class="gmail_default"><br></div><div class="gmail_default">Looking at the code in clang (e.g. CodeGenFunction::EmitAutoVarAlloca) it is pretty clear to me that when the lifetime marker is first manufactured, it is placed into the entry block. I don't know enough about how Polly operates to understand why it is migrating the lifetime in question down into the block containing the exit... but it seems to me that this is really the crux of the problem.</div><div class="gmail_default"><br></div><div class="gmail_default">Thanks, Than</div><div class="gmail_default" style="font-size:small"><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 31, 2017 at 8:02 AM, Michael Kruse 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 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. According to Than<br>
McIntosh the problem is that StackColoring currently does not<br>
correctly handle the situation.<br>
<br>
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>
<div class="HOEnZb"><div class="h5"><br>
Michael<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>
</div></div></blockquote></div><br></div>