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

[Shuxin Yang]

On 9/6/13 9:39 PM, Daniel Berlin wrote:
> On Fri, Sep 6, 2013 at 8:39 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:
>> Hi, Daniel:
>>
>>    Thank you for your speedy feedback.
>>
>>
>> On 9/6/13 8:03 PM, Daniel Berlin wrote:
>>> Is there a reason to not just use a better GVN algorithm?
>>> Why add a set of complicated conditions to fold code on the fly, when
>>> almost any other GVN algorithm than the current one would properly
>>> detect the cases you are talking about.
>>>
>>> In particular, you say: "GVN prove x > 0, making the else-clause dead.
>>> If GVN were not able to prune
>>> dead-edge <else-clause, JoinNode>, value "foo" (could be constant) would
>>> not
>>> be able propagated to S3."
>>>
>>> This is false.  It does not need to prune this edge, it just needs an
>>> algorithm that doesn't consider the edge taken if the edge is provably
>>> not taken.
>> Yes, we can "ignore" the dead code.
>> As I mentioned in my previous mail, GVN can proceed by ignoring dead stuff.
>> \
>> the problem is that it will end up with the code where def does not dominate
>> its uses.
> Errr, it can remove it at the end.
But many helper routines relies on precise dom-info, and
LLVM's GVN perform some PRE as well. The load PRE we certainly cannot 
afford
to ignore them.

On the other hand, I'm not sure how risky it will be if we keep the IR 
imprecise.

Maybe we need a brand new GVN.  I heard you are writing brand new one. 
How soon
will it be available?

>   I'm not saying never remove it,
> i'm saying your method, which is to patch in an incremental
> DF/dominator tree update algorithm, seems like a very high maintenance
> burden (these algorithms are non-trivial to understand) for what it
> does.
There is only about 10 lines of code for maintaining DT -- just move the
node N, which were adjacent to the dead code, to the
least-common-ancestor(preds(N)).

>
> It's only necessary because the current actual GVN algorithm is very
> dumb, and can't see this stuff on it's own.
>
>
>> Unless following passes can "ignore" dead code in the same way,
>> the verifier and other passes will complains.
> I'm saying it's not necessary to do on the fly.
I hate maintain DT on-the-fly as well. But the only thing I can do without
it is simply run GVN twice:-)

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

> It is actually becoming
> more and more like GCC's old dominator optimization every day - a grab
> bag of optimizations that all fall under some abstract notion of
> value based redundancy elimination, but aren't really the same, and
> are not unified in any real way.  This is okay if it was not a compile
> time sink, but it's a huge one now, and adding stuff like this only
> makes it worse.
>
>
>>> and is already a compile time sink.
>> Alias analysis bear the blame, It remember alias analysis account for 1/3+
>> of GVN compile-time.
> This is directly because of the algorithm in GVN and how it works.
I don't think so.  I believe the culprit is lacking a sparse way to 
represent
mem-dep -- when GVN try to figure out a the set of mem-opt a particular 
load/store
deps on, the mem-dep search all over the place.

> My suggestion would be to sit down and design something that actually
> covers the case we want, instead of just adding more stuff to GVN as
> it exists now, trying to get one oddball case at a time.
> This is going to have to be done at some point, and while I understand
> you don't want to have to be the one to do it, and I certainly can't
> make you, I can tell you that doing something like this is making the
> eventual job a bunch harder.
Sound like I have to ditch this patch. I don't think I can come up a better
way, considering the combination of what we have today.

How soon will your new GVN available. Dose it tackle this problem as well?