[Patch] GVN fold conditional-branch on-the-fly

[Shuxin Yang]

I talked with Nadav this morning, we are going to drag some utility 
function out of GVN,

As the compile time impact, I believe I told you before. The short 
answer is nothing,
I physically measure "nothing" and told you why it is nothing -- this 
code kicks in only when
it come across fold-able conditional branch, and in this case, it looks 
ahead about 16 blocks,
which is the major cost. If we were pedantic, the algorithm complexity 
is O(n) where
the n is # of fold-able conditional branch.



On 9/11/13 5:01 PM, Daniel Berlin wrote:
> Sorry, not trying to drag this out, just got extremely busy with
> something else very suddenly.
>
> On Tue, Sep 10, 2013 at 10:18 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>> ping?
>>
>>
>> On 9/9/13 10:43 PM, Shuxin Yang wrote:
>>> Hi,
>>>
>>>   These helper routines are used to save time. I don't need to construct
>>> dominance frontier for GVN.
>>> If DF were available, we don't need them at all.
>>>
>>>   I can pull all these stuff in another file/class, and only expose 3
>>> member functions.
>>>   - tryFoldCondBranch(br)
>>>   - isDeadBlock(BB)
>>>    - deleteBlock()
>>>
>>>   How does this sound to you?
>>>
> This doesn't really answer many of the concerns i raised: around
> compile time impact (i still haven't seen numbers in this thread about
> compile time impact, we have plenty of known 'gvn is slow' code to try
> this on), around how you chose the number of blocks in the DF getting
> function, about whether this has been tested on code with large
> numbers of branches or anything likely to show regressions, and around
> the overall design in terms of *what exact cases we are trying to get
> and why these particular choices were made*.  That is, I see an
> implementation, not a design.
>
> That said, i've said my peace, so i'm not going to stand in the way anymore.
>
>>>    If we judge added complexity by the # of interaction point to
>>> the existing code, this is quite a small change.  If you want to quantify
>>> complex by LOC,
>>> please explain why your simpler rudimentary implementation has about 2x
>>> LOCs of
>>> existing complicated GVN.
>>>
>>>