[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:57 PM, Jiangning Liu <liujiangning1 at gmail.com>
wrote:

> HI Dan,
>
> 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.
>>
>
> I don't really see the wrong lowering direction.
>


You are taking values that  got evaluated, went "down" the lattice to
overdefined, and reevaluating them, and raising them back *up* the lattice
to "not overdefined".
That is definitely going in the wrong direction on the lattice.

What am I missing?
Besides the compile time problems, in such situations, you can also make
the algorithm no longer fixpoint, ever.


>
>
>> 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 :)
>>
>
> I personally think this algorithm itself is powerful. But I'm not sure
> what would happen if we don't bail out of the lowering early before we
> could lower the value completely as possible as we could at compile time. I
> was told the algorithm was initially designed to save compile time. I
> personally think it might true in terms of the number of values to be
> checked, but I don't really have data to justify it. At least for the case
> I'm fixing with the new patch, the large number of basic block is really a
> problem.
>
> Thanks,
> -Jiangning
>
>
>> 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/20140922/03e34f95/attachment.html>