[llvm-dev] IR liveness analysis in 2019

[Son Tuan VU via 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>