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

[Than McIntosh via llvm-dev]

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.

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?

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.

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, Than


On Wed, Mar 29, 2017 at 7:39 AM, Michael Kruse <llvmdev at meinersbur.de>
wrote:

> Hi @all,
>
> I hit a problem with Polly-generated code which llvm.org/PR32251 . The
> problem is how @llvm.lifetime.start is placed after Polly transformed
> the code. Basically Polly transformed
>
>     llvm.lifetime.start(&var)
>     [...]
>     llvm.lifetime.end(&var)
>
> into
>
>     if (c) {
>       llvm.lifetime.start(&var)
>     }
>     [...]
>     llvm.lifetime.end(&var)
>
>
> now the llvm.lifetime.end is not dominated by the corresponding
> llvm.lifetime.start. As far as I understand the documentation [1] this
> is a valid construction, meaning that the value of var is only
> undefined before some point when c is true. I don't expect the
> compiler to exploit this.
>
> However, this miscompiles since r270559 ("Rework/enhance stack
> coloring data flow analysis", https://reviews.llvm.org/D18827)
>
> I modified Polly's code generator to produce
>
>     if (c) {
>       llvm.lifetime.start(&var)
>     } else {
>       llvm.lifetime.start(&var)
>     }
>     [...]
>     llvm.lifetime.end(&var)
>
> and it does not miscompile anymore. However, Polly is currently is not
> able to compute the lifetime in the general case.
>
> Question: Is this a bug in the stack coloring algorithm or should this
> be fixed in Polly?
>
>
> Side question: Are there any invalid combinations of
> llvm.lifetime.start/end such as
>
>     llvm.lifetime.end(&var)
>     llvm.lifetime.start(&var)
>
> (my interpretation would be that var is always dead)? With invalid I
> mean that the compiler does not need to handle this case.
>
> Regards,
> Michael
>
> [1] http://llvm.org/docs/LangRef.html#llvm-lifetime-start-intrinsic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170329/1724d00b/attachment.html>