<div dir="ltr"><div class="gmail_default" style="font-size:small">Hello Michael,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Perhaps you could share a little more detail about your test case and the specific failure mode. Without seeing the uses of the variable, it's hard to tell how the new algorithm is going to behave. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">More specifically, when you say "miscompiles", I assume that this means that StackColoring has overlapped two variables whose lifetimes are on fact not disjoint after all? </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The pattern you describe (where the lifetime start doesn't strictly dominate the lifetime end) is referred to in the current stack coloring source code as a "degenerate" lifetime; there is code that specifically looks for such cases and treats them more conservatively than well-formed lifetimes (this is described in the "Implementation Notes" comment in the source starting around line 90). The key question however is where the uses of the variable are relative to the lifetime start/end markers.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For your side question (are there invalid ways to use lifetime start/end), I don't think I really have a good answer there. What I have seen on my own is that lifetime start/end markers tend to start out in more reasonable/sane configurations, but then can be perturbed / rearranged during optimization, resulting in orderings that don't always make sense (such as the case you cite). My feeling is that this is OK, and that the stack coloring code should be able to tolerate that sort of perturbation.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks, Than</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 29, 2017 at 7:39 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">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>
</blockquote></div><br></div>