<div dir="ltr">I think lifetime start / end are poorly specified and need to be replaced. However, I've said that a lot, I haven't done anything about it myself, and people are probably tired of hearing me say it by now.<div><br></div><div>I think Polly's transform is valid and this is a bug in stack coloring. Stack coloring needs to be able to cope with unmatched lifetime intrinsics.</div></div><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:0 0 0 .8ex;border-left:1px #ccc solid;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. 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>
<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>
<br>
Question: Is this a bug in the stack coloring algorithm or should this<br>
be fixed in Polly?<br>
<br>
<br>
Side question: Are there any invalid combinations of<br>
llvm.lifetime.start/end such as<br>
<br>
    llvm.lifetime.end(&var)<br>
    llvm.lifetime.start(&var)<br>
<br>
(my interpretation would be that var is always dead)? With invalid I<br>
mean that the compiler does not need to handle this case.<br>
<br>
Regards,<br>
Michael<br>
<br>
[1] <a href="http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic" rel="noreferrer" target="_blank">http://llvm.org/docs/LangRef.<wbr>html#llvm-lifetime-start-<wbr>intrinsic</a><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>
</blockquote></div><br></div>