llvm dev - Mar 2019 - IR liveness analysis in 2019

Hi Quentin,

Well what I'm trying to do is that, given a (maybe really big) set of
particular points Pi, find out all the SSA variables Vi that are live at
these points (i.e. def(Vi) dom Pi and at least one use(Vi) is reachable
from Pi). The problem with classic def-use chains and dominance property is
that I have to do this query for each point Pi and each variable Vi, which
does not scale for big programs or for big set of particular points.

Cheers,

Son Tuan Vu


On Thu, Mar 7, 2019 at 8:13 PM Quentin Colombet <qcolombet at apple.com>
wrote:
> Hi,
>
> On Mar 6, 2019, at 9:58 AM, Son Tuan VU via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Hello,
>
> I found this thread back in 2014 [1] . Does anyone know if there has been
> any attempt to answer this request?
>
> To clarify, I am looking for an analysis that computes the textbook
> definition of variable liveness: "given a SSA value V and a point P,
is
> there a possible path from P to any use of V?" which is equivalent to
"is V
> live at point P?"
>
> I can write something myself (and will if need be), but just want to avoid
> reinventing the wheels in case improvements have been made since 2014. If
> not, what's the best way to contribute this analysis to LLVM? I mean,
for
> example, is "Computing Liveness Sets for SSA" by Boissinot  [2]
efficient
> enough to be implemented in LLVM?
>
>
> This one should be efficient enough.
> That said, what are you trying to achieve?
>
> The reason we don’t have such algorithm in LLVM IR is because we don’t
> need it. Usually def-uses chains and dominance property are enough for what
> the optimizers want to do.
>
> Or should I find a better algorithm to solve this?
>
> [1] http://lists.llvm.org/pipermail/llvm-dev/2014-July/074793.html
> [2] http://hal.inria.fr/docs/00/58/53/03/PDF/RR-7503.pdf
>
> Thanks for your help,
>
> Cheers
>
> Son Tuan Vu
> _______________________________________________
> 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/20190307/8c51a0c4/attachment.html>

> On Mar 7, 2019, at 2:01 PM, Son Tuan VU <sontuan.vu119 at gmail.com>
wrote:
> 
> Hi Quentin,
> 
> Well what I'm trying to do is that, given a (maybe really big) set of
particular points Pi, find out all the SSA variables Vi that are live at these
points (i.e. def(Vi) dom Pi and at least one use(Vi) is reachable from Pi).
That sounds like answering a liveness query indeed, but what do you do with this
information?
> The problem with classic def-use chains and dominance property is that I
have to do this query for each point Pi and each variable Vi, which does not
scale for big programs or for big set of particular points.
> 
> Cheers,
> 
> Son Tuan Vu
> 
> 
> On Thu, Mar 7, 2019 at 8:13 PM Quentin Colombet <qcolombet at apple.com
<mailto:qcolombet at apple.com>> wrote:
> Hi,
> 
>> On Mar 6, 2019, at 9:58 AM, Son Tuan VU via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> Hello,
>> 
>> I found this thread back in 2014 [1] . Does anyone know if there has
been any attempt to answer this request?
>> 
>> To clarify, I am looking for an analysis that computes the textbook
definition of variable liveness: "given a SSA value V and a point P, is
there a possible path from P to any use of V?" which is equivalent to
"is V live at point P?"
>> 
>> I can write something myself (and will if need be), but just want to
avoid reinventing the wheels in case improvements have been made since 2014. If
not, what's the best way to contribute this analysis to LLVM? I mean, for
example, is "Computing Liveness Sets for SSA" by Boissinot  [2]
efficient enough to be implemented in LLVM?
> 
> This one should be efficient enough.
> That said, what are you trying to achieve?
> 
> The reason we don’t have such algorithm in LLVM IR is because we don’t need
it. Usually def-uses chains and dominance property are enough for what the
optimizers want to do.
> 
>> Or should I find a better algorithm to solve this?
>> 
>> [1] http://lists.llvm.org/pipermail/llvm-dev/2014-July/074793.html
<http://lists.llvm.org/pipermail/llvm-dev/2014-July/074793.html>
>> [2] http://hal.inria.fr/docs/00/58/53/03/PDF/RR-7503.pdf
<http://hal.inria.fr/docs/00/58/53/03/PDF/RR-7503.pdf>
>> 
>> Thanks for your help,
>> 
>> Cheers
>> 
>> Son Tuan Vu
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/20190307/cc8704f6/attachment.html>

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