[llvm] r215343 - In LVI(Lazy Value Info), originally value on a BB can only be caculated once,

Daniel Berlin dberlin at dberlin.org
Fri Sep 19 12:44:16 PDT 2014


On Fri Sep 19 2014 at 11:54:41 AM Daniel Berlin <dberlin at dberlin.org> wrote:

> Hey Jiangning,
> Note that this also changes it from being O(n) to O(n^2) in terms of
> number of iterations, since things can go back up the lattice now.  It also
> should never happen :)
>
>
> In the comments, you say
> +  // Once this BB is encountered, Val's value for this BB will not be
> Undefined
> +  // any longer. When we encounter this BB again, if Val's value is
> Overdefined,
> +  // we need to compute its value again.
> +  //
> +  // For example, considering this control flow,
> +  //   BB1->BB2, BB1->BB3, BB2->BB3, BB2->BB4
> +  //
> +  // Suppose we have "icmp slt %v, 0" in BB1, and "icmp sgt %v, 0" in
> BB3. At
> +  // the very beginning, when analyzing edge BB2->BB3, we don't know %v's
> value
> +  // in BB2, and the data flow algorithm tries to compute BB2's
> predecessors, so
> +  // then we know %v has negative value on edge BB1->BB2. And then we
> return to
> +  // check BB2 again, and at this moment BB2 has Overdefined value for %v
> in
> +  // BB2. So we should have to follow data flow propagation algorithm to
> get the
> +  // value on edge BB1->BB2 propagated to BB2, and finally %v on BB2 has a
> +  // constant range describing a negative value.
>
> This does not explain why BB2's value of %v started out as overdefined.
> Somewhere in here, either propagation order is wrong, or the CFG has some
> weirdness (is the CFG above the complete description of the testcase? Are
> there critical edges).
>
> IMHO, You should never have a case where things to go the wrong direction
> in the lattice.
>

To be a little more forceful here:

The base invariant of all of these kinds of algorithms (value range
analysis, constant propagation, etc) is that values only go in one
direction on the lattice.
If you have found a case where this is not true, either
1. The implementation is buggy/broken
2. The algorithm isn't powerful enough to handle what you really want to
happen, and you should change algorithms :)

One of these is the real problem.

There is no case where the right solution should involved reevaluating
values and moving them in the wrong direction on the lattice.
Besides hiding whatever the real problem is, it also changes the time
bounds of the algorithm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140919/af6a8c89/attachment.html>


More information about the llvm-commits mailing list