llvm dev - Mar 2019 - IR liveness analysis in 2019

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

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

Hello all,

Thanks for your replies.
Indeed, I do not really know how to solve Jeremy's use case. My use case is
much simpler, I only want to have a list of variables that are live at an
interesting point and insert a new instruction that consumes the live
variable at that point.

So do you think that people do want a liveness analysis at the IR level?

Son Tuan Vu


On Fri, Mar 8, 2019 at 7:12 PM Quentin Colombet via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20190312/479597f7/attachment.html>