<div dir="ltr"><div class="gmail_default" style="font-size:small">OK, thanks for the additional info.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Sure, if you can send me a runnable test case, I can spend some time in the debugger to learn more about how things are going wrong. It seems unlikely that I would be able to identify the issue just looking at IR dumps or source code, though.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Cheers, 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 9: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"><span class="">2017-03-29 14:19 GMT+02:00 Than McIntosh <<a href="mailto:thanm@google.com">thanm@google.com</a>>:<br>
> Hello Michael,<br>
><br>
> Perhaps you could share a little more detail about your test case and the<br>
> specific failure mode. Without seeing the uses of the variable, it's hard to<br>
> tell how the new algorithm is going to behave.<br>
<br>
</span>The test case that fails as mentioned in <a href="http://llvm.org/PR32251" rel="noreferrer" target="_blank">llvm.org/PR32251</a> is SPEC<br>
CPU's 2006 444.namd (version 1.1). In its main function there are<br>
several structs on the stack and annotated with lifetime markers.<br>
Polly does the previously mentioned transformation on one of those<br>
markers (which is not intended).<br>
<br>
Because the SPEC2006 is proprietary, I am not sure that I can share<br>
any code on the public mailing list. If I can convince you to look<br>
into it, I can send you source and the IR Polly is generating.<br>
<span class=""><br>
<br>
> More specifically, when you say "miscompiles", I assume that this means that<br>
> StackColoring has overlapped two variables whose lifetimes are on fact not<br>
> disjoint after all?<br>
<br>
</span>I diagnosed a miscompile because test-suite found that the program's<br>
output defers from the reference output. I did not look specifically<br>
what it does wrong. It did not miscompile before r270559 (git bisect).<br>
<span class=""><br>
<br>
> The pattern you describe (where the lifetime start doesn't strictly dominate<br>
> the lifetime end) is referred to in the current stack coloring source code<br>
> as a "degenerate" lifetime; there is code that specifically looks for such<br>
> cases and treats them more conservatively than well-formed lifetimes (this<br>
> is described in the "Implementation Notes" comment in the source starting<br>
> around line 90). The key question however is where the uses of the variable<br>
> are relative to the lifetime start/end markers.<br>
<br>
</span>I only overflew <a href="https://reviews.llvm.org/D18827" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D18827</a> to find whether that<br>
case is mentioned, but couldn't find something.<br>
<br>
The degenerate case described moves the computation of the pointer<br>
before the LIFETIME_START marker, but the markers themselves are still<br>
(post-)dominating each other. As not being familiar with the code,<br>
this does not seem to be equivalent to my case.<br>
<span class=""><br>
<br>
> For your side question (are there invalid ways to use lifetime start/end), I<br>
> don't think I really have a good answer there. What I have seen on my own is<br>
> that lifetime start/end markers tend to start out in more reasonable/sane<br>
> configurations, but then can be perturbed / rearranged during optimization,<br>
> resulting in orderings that don't always make sense (such as the case you<br>
> cite). My feeling is that this is OK, and that the stack coloring code<br>
> should be able to tolerate that sort of perturbation.<br>
<br>
</span>Thanks for your thoughts.<br>
<span class="HOEnZb"><font color="#888888"><br>
Michael<br>
</font></span></blockquote></div><br></div>