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

[Daniel Berlin via llvm-dev]

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.



Which is not sensible but valid.

It's not sensible in the sense that it's not clear what "before" means in
the documentation. There are several reasonable interpretations.
IE if the path through C is never taken, does that mean the lifetime never
starts?


The only sensible approach i know of is that every path to a lifetime end
must hit a lifetime.start or the lifetime is  UB along that path.
That would outlaw the above :P

You could also go with the scope of lifetime.end is formed by the members
of the post-dominance frontier, etc, and remove 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.
>

i do not believe it can be correct in all cases without correct dominance
and post-dominance info.



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

Of course, nothing is.
But they are also metadata, so you could just drop them if you wanted.


>
> Question: Is this a bug in the stack coloring algorithm or should this
> be fixed in Polly?
>

It's a bug in the semantics of lifetime.start/lifetime.end
 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170330/d3e0d4cb/attachment.html>