[llvm-commits] Do more conditional propagation in GVN

[Duncan Sands]

Hi Peter,

> Sorry, you sent me this quite a while ago and I never got back to you about it. I think it's very worthwhile. I was trying to do something similar in SimplifyCfg but it was getting very messy.

this is doing something different to that one.  Currently if we branch on a
condition %cmp = icmp eq %a, %b, then %cmp is replaced by "true" under the
true edge of the branch, and also %a is replaced by %b there *as long as %b
is a constant*.  The patch I sent you relaxes this and replaces %a by %b
whether %b is a constant or not.  The problem is that this increases compile
time quite a lot for a gain that isn't spectacular.  However I had some ideas
for improving the compile time.  If they work out I will apply it.

The patch I just posted replaces the inverse expression "icmp ne %a, %b" with
false under the true edge of the branch.

Ciao, Duncan.

>
> Thanks
> Pete
>
> Sent from my iPhone
>
> On Feb 26, 2012, at 10:06 AM, Duncan Sands<baldrick at free.fr>  wrote:
>
>> Hi all, suppose we have
>>
>>     %cmp = icmp eq i32 %x, %y
>>     br i1 %cmp, label %same, label %different
>>   same:
>>     %cmp2 = icmp eq i32 %x, %y
>>     %cmp3 = icmp ne i32 %x, %y
>>
>> Right now GVN will replace %cmp2 with "true" because you can only get to
>> block "same" if %cmp is true, and %cmp2 is the same as %cmp.  But it
>> doesn't replace %cmp3 with false.  The attached patch implements this
>> (when the branch condition is any comparison, not just an equality
>> comparison).  Currently no pass does this (tested using -std-compile-opts).
>>
>> The logic fires here and there.  It zaps two compares and two blocks in bzip2
>> because the compares were replaced with constants thanks to this.  In "gcc as
>> one big file" it zaps 50 or so comparisons, resulting in some minor knock-on
>> simplifications.  On sqlite3, which showed the most compile time slowdown when
>> the original logic was implemented, the compile time goes up by 2%, while in
>> return it zaps about 40 or so comparisons resulting in some minor knock-on
>> simplifications.
>>
>> I didn't implement this because I needed it, I implemented it because I
>> realized that it could be done quite easily.  But is it worth it?  Any
>> opinions?
>>
>> Ciao, Duncan.
>> <oppprop.diff>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits