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

[Daniel Berlin]

>> 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?
if E is  not at least *partially* anticipatable at that point, it can't be.
However, the current PRE implementation requires *full* anticipation,
which is not necessary in all cases.
It also requires certain types of availability which are not strictly
necessary (IE it doesn't even catch all the base cases in the GVN-pre
thesis).

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

http://cs.wheaton.edu/~tvandrun/writings/thesis.pdf

Starting on page 81, use any of the examples for partial anticipation.
If you transform these examples to talk about loads properly, it will
miss every one of them. It does not understand how to perform these
dataflow calculations.

There are plenty of examples you can come up with outside of partial
anticipation.
As I said, the partial anticipation cases it misses are not bad,
because they account for a small percent of cases.
There are more normal cases it misses due to the heuristics and other
algorithm issues.
GVN's load PRE was never intended to be a complete PRE, but to catch a
lot of common cases at relatively low expense.
I don't think anyone has ever claimed it to be complete, so i'm a bit
surprised to hear that someone thinks it catches all the cases any
"regular" PRE would. It was never intended to, and certainly doesn't.

If you want to eliminate more loads, there is lower hanging fruit in
GVN than the PRE part ....