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

[Jiangning Liu]

Hi Dan,


2014-09-20 2:54 GMT+08:00 Daniel Berlin <dberlin at dberlin.org>:

> 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 :)


This might be true. The algorithm originally bails out immediately whenever
a value is lowered to be overdefined, and now it will be changed to be
searching the predecessor blocks if it is overdefined value. But other
values that are lower than overdefined value will never be lowered again.If
we use typical data flow algorithm to lower the lattice, the time
complexity should be proportional to the depth of loop. So in reality the
time complexity is OK. And I don't see big compile-time overhead with my
new patch by adding a threshold by controlling the number of basic blocks
to be checked.


>
>
> 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.
>

This is because the lattice will be lowered to be overdefined as soon as it
has ever been lowered/encountered once. For this case, when checking the
value on edge BB2->BB3, it will be immediately lowered from undefined to
overdefined for BB2. And this value can actually be further lowered to be a
constant range after checking BB2's predecessors. So the lowering procedure
for this value is like,

undefined -> overdefined -> constant range.

  // Otherwise, this is the first time we're seeing this block.  Reset the
  // lattice value to overdefined, so that cycles will terminate and be
  // conservatively correct.
  BBLV.markOverdefined();

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).
>

This is not the case, and I don't see the wrong propagation order. Because
this is a lazy value info calculation, and the customers of this algorithm
may invoke it anytime, and at that time it is possible that there isn't any
cached value for the value being checked yet. And eventually we have to
lower that value from scratch.


>
> IMHO, You should never have a case where things to go the wrong direction
> in the lattice.
>

Yes. Agree.


>
>
> On Thu Sep 11 2014 at 8:47:56 PM Jiangning Liu <liujiangning1 at gmail.com>
> wrote:
>
>> Hi Joerg,
>>
>> Thanks for your command line, and it works!
>>
>> I've sent out a patch email to fix this problem, and you may want to have
>> a look.
>>
>> Sorry for any inconvenience caused!
>>
>> Thanks again,
>> -Jiangning
>>
>> 2014-09-09 17:50 GMT+08:00 Joerg Sonnenberger <joerg at britannica.bec.de>:
>>
>>> On Tue, Sep 09, 2014 at 11:41:00AM +0800, Jiangning Liu wrote:
>>> > Hi Joerg,
>>> >
>>> > Sorry to know about this... I just came back from mid-autumn holiday...
>>> >
>>> > Can you tell me how you measured the memory consumption for llvm?
>>>
>>> Build with /usr/bin/time -v clang -O2 -c.
>>>
>>> Joerg
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140922/246b3d2e/attachment.html>