[llvm-dev] Well-formed @llvm.lifetime.start and @llvm.lifetime.end intrinsics

[Michael Kruse via llvm-dev]

2017-03-29 14:19 GMT+02:00 Than McIntosh <thanm at google.com>:
> Hello Michael,
>
> 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.

The test case that fails as mentioned in llvm.org/PR32251 is SPEC
CPU's 2006 444.namd (version 1.1). In its main function there are
several structs on the stack and annotated with lifetime markers.
Polly does the previously mentioned transformation on one of those
markers (which is not intended).

Because the SPEC2006 is proprietary, I am not sure that I can share
any code on the public mailing list. If I can convince you to look
into it, I can send you source and the IR Polly is generating.


> 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?

I diagnosed a miscompile because test-suite found that the program's
output defers from the reference output. I did not look specifically
what it does wrong. It did not miscompile before r270559 (git bisect).


> 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.

I only overflew https://reviews.llvm.org/D18827 to find whether that
case is mentioned, but couldn't find something.

The degenerate case described moves the computation of the pointer
before the LIFETIME_START marker, but the markers themselves are still
(post-)dominating each other. As not being familiar with the code,
this does not seem to be equivalent to my case.


> 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.

Thanks for your thoughts.

Michael