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

[Reid Kleckner via llvm-dev]

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.

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.

On Wed, Mar 29, 2017 at 4:39 AM, Michael Kruse via llvm-dev <
llvm-dev at lists.llvm.org> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170329/d858f5af/attachment.html>