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

[Daniel Berlin]

On Sun, Sep 21, 2014 at 6:45 PM, Jiangning Liu <liujiangning1 at gmail.com>
wrote:

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


This not lowering.

undefined is one end of the lattice.
overdefined is the other.
constant is in the *middle* of the lattice.

No matter which you call top and which you call bottom, the value has
reached the end of the lattice.
It should never go back to the middle.

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

So can you explain how you aren't doing this?

It looksl ike you think the lattice goes
undefined
overdefined
constant

That should 100% not be the case
the lattice order should be
undefined
constant
overdefined

undefined means you don't know
constant means it has one value.
overdefined means it has too many values

This is a traditional value range lattice (though sometimes there are more
things in the middle).
There is no way you should go from overdefined back to constant.




>
>>
>>
>> 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/ceca0fe3/attachment.html>