[llvm-dev] IR liveness analysis in 2019

[Quentin Colombet via llvm-dev]

Thanks Jeremy for the use case!

I have a hard time to see how that would work in practice.

Essentially, in your example, you have to detect that count went out of liveness, so that means we need to somehow maintain the original liveness of the program to do that comparison and that’s where I don’t see how we can do that.
Also, ultimately IIUC we want to mark the extended count value as being count, but it seems to me that this is as hard if not harder to teach the optimization how to propagate this information in the first place instead of analyzing the liveness difference.

> On Mar 8, 2019, at 6:50 AM, Jeremy Morse via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> I may have a use-case for IR liveness analysis, although it's in the
> context of debuginfo. Using the sample code from this bug report [0],
> which is a fairly trivial loop:
> 
>    int foo(int count) {
>      int result = 0;
>      for (unsigned long long ix = start; ix != count; ++ix)
>        result += external(ix);
>      return result;
>    }
> 
> On x86_64 the 32-bit "count" comparison to 64 bit "ix" necessitates
> sign extension of "count". That sign extension gets hoisted out of the
> loop, the original value of "count" goes out of liveness, and the
> produced debuginfo has no variable location for "count" across the
> loop body. I can generate similar examples involving the movement of
> pointer bitcasts that lead to pointer variables getting lost.
> 
> We can easily generate variable location expressions to recover the
> value of "count" from the sign-extended value, so that "count" has a
> location across the loop, but (I believe) we'd need a liveness
> analysis to determine where & when in the IR to generate such
> locations. (Debuginfo of course has to "cope" with things going out of
> liveness, whereas liveness has to preserve the functioning of
> everything else in IR).
> 
> [0] https://bugs.llvm.org/show_bug.cgi?id=38997
> 
> --
> Thanks,
> Jeremy
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev