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

[Michael Kruse via llvm-dev]

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