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

[Shuxin Yang]

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. Unless following passes can "ignore" dead code in the same way,
the verifier and other passes will complains.

>
> There are plenty of these algorithms, most even more powerful than the
> test cases you want done, for example,
> http://dl.acm.org/citation.cfm?id=512536



But, I don't want to re-implement GVN from ground up:-).  I'm not sure
theoretically better algorithm can significantly speed up the performance.
(e.g. I almost never find a SCC-GVN opportunities in real-world apps)

As far as I can tell,  what  GVN at llvm really need to improve is detecting
mem-op redundancy. But this is not GVN's fault.

 >GVN is getting more and more complicated,
GVN is almost always complicated:-)

 >and is already a compile time sink.
Alias analysis bear the blame, It remember alias analysis account for 
1/3+ of GVN compile-time.

 > Is this really the best way to add this functionality?
The "best" way I can figure out considering complexity and common-case 
in practices:-)

What is your suggestion.? Thanks