# [LLVMdev] Lost instcombine opportunity: "or"s of "icmp"s (commutability)

Edward Lee eslee3 at uiuc.edu
Wed Oct 8 09:59:46 PDT 2008

```instcombine can handle certain orders of "icmp"s that are "or"ed together:
x != 5 OR x > 10 OR x == 8 becomes..
x != 5 OR x == 8 becomes..
x != 5

However, a different ordering prevents the simplification:
x == 8 OR x > 10 OR x != 5 becomes..
%or.eq8.gt10 OR x != 5
and that can't be simplified because we now have an "or" OR "icmp".

What would I need to implement to restore the commutative property?

Perhaps a first stab would be to take (A|B)|C create two binaryOp A|C
and B|C and recursively call visitOr on each of them to see if they
simplify. Using the example above..

Before:
%or.eq8.gt10 = .. ; [uses=1]
%res = or %or.eq8.gt10, %ne5 ; original instruction

After:
%or.eq8.gt10 = .. ; [uses=0]
%or.eq8.ne5 = %ne5 ; instcombine recursively simplified this [uses=1
or 0 see next]
%res = or %or.eq8.ne5, %gt10 ; even better: %res = or %ne5, %gt10

The recursive call of A|C would also let C see further "or"s, so if A
is actually composed of (a1|a2), it could potentially try to simplify
a1|C and a2|C.

I'm not entirely sure right now, but potentially there could be issues
of creating too many additional "or" instructions. E.g., %or.eq.8.gt10
originally had more than 1 use.

Am I on the right track (or does LLVM already support this in another
optimization pass?)

Ed

```