<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 29, 2017 at 4:39 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi @all,<br>
<br>
I hit a problem with Polly-generated code which <a href="http://llvm.org/PR32251" rel="noreferrer" target="_blank">llvm.org/PR32251</a> . The<br>
problem is how @llvm.lifetime.start is placed after Polly transformed<br>
the code. Basically Polly transformed<br>
<br>
    llvm.lifetime.start(&var)<br>
    [...]<br>
    llvm.lifetime.end(&var)<br>
<br>
into<br>
<br>
    if (c) {<br>
      llvm.lifetime.start(&var)<br>
    }<br>
    [...]<br>
    llvm.lifetime.end(&var)<br>
<br>
<br>
now the llvm.lifetime.end is not dominated by the corresponding<br>
llvm.lifetime.start. </blockquote><div><br></div><div><br></div><div>Which is not sensible but valid.</div><div><br></div><div>It's not sensible in the sense that it's not clear what "before" means in the documentation. There are several reasonable interpretations.</div><div>IE if the path through C is never taken, does that mean the lifetime never starts?</div><div><br></div><div><br></div><div>The only sensible approach i know of is that every path to a lifetime end must hit a lifetime.start or the lifetime is  UB along that path.</div></div><div class="gmail_quote">That would outlaw the above :P<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">You could also go with the scope of lifetime.end is formed by the members of the post-dominance frontier, etc, and remove lifetime.start.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As far as I understand the documentation [1] this<br>
is a valid construction, meaning that the value of var is only<br>
undefined before some point when c is true. I don't expect the<br>
compiler to exploit this.<br></blockquote><div><br></div><div>i do not believe it can be correct in all cases without correct dominance and post-dominance info.</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">
<br>
However, this miscompiles since r270559 ("Rework/enhance stack<br>
coloring data flow analysis", <a href="https://reviews.llvm.org/D18827" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D18827</a>)<br>
<br>
I modified Polly's code generator to produce<br>
<br>
    if (c) {<br>
      llvm.lifetime.start(&var)<br>
    } else {<br>
      llvm.lifetime.start(&var)<br>
    }<br>
    [...]<br>
    llvm.lifetime.end(&var)<br>
<br>
and it does not miscompile anymore. However, Polly is currently is not<br>
able to compute the lifetime in the general case.<br></blockquote><div><br></div><div>Of course, nothing is.</div><div>But they are also metadata, so you could just drop them if you wanted.</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">
<br>
Question: Is this a bug in the stack coloring algorithm or should this<br>
be fixed in Polly?<br></blockquote><div><br></div><div>It's a bug in the semantics of lifetime.start/lifetime.end</div><div> :)</div><div><br></div></div></div></div>