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

[Shuxin Yang]

On 9/7/13 4:02 PM, Daniel Berlin wrote:
> On Sat, Sep 7, 2013 at 11:27 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>> On 9/7/13 9:14 AM, Daniel Berlin wrote:
>>>>>>> GVN is getting more and more complicated,
>>>>>> GVN is almost always complicated:-)
>>>>> It's really not.  LLVM's GVN is not really a GVN.  It's really a very
>>>>> complicated set of interleaved analysis and optimization that happens
>>>>> to include some amount of value numbering.
>>>> LLVM GVN is a old-style GVN + some PRE.  But for the PRE part, I don't
>>>> think LLVM GVN is complicated at all.
>>> No, it's not. It is a very simple PRE that tries to catch a few cases.
>> I disagree.  The PRE in LLVM GVN has two part, one tackle load, the other
>> one tackle
>> simple expr in diamond-shaped cfg. I believe the former catch *all* load
>> PREs (depending
>> on alias analysis's result).
> It absolutely positively does not.
> It catches one form of partial availability, fully anticipatable
> expressions (and not even all of these, i believe). It certainly does
> not catch *any* form of partially available, partially anticipatable
> expressions, or even fully available, partially anticipatable
> expressions.
>
> While not as common, based on experience with GVN-PRE, and knowing
> it's limitations (which include punting on multiple-successor cases,
> only inserting one load, etc), I'd say it misses ~20% of cases it
> could eliminate by doing this (the PA-PA case is rare, i'd say 2-3%,
> though it did show up in some performance sensitive apps. The FA-PA
> case is significantly less rare. The other random restrictions hurt
> slightly too).
>
I'm not sure I can understand, how can and expr E is partially redundant 
at point
P, if E is not andiciptable at that point?

Anyway, can you give an example that GVN's load-PRE miss?