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

[Daniel Berlin]

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