In simplify_mask_or(), two calls to simplify_mask_or_and() are made: one for each operand of the OR instruction. These two calls are guarded by a test checking the presence of the AND instruction. If it is the case for the first operand, the second operand is never considered for simplification, even if no simplifications have been made. Fix this by testing the return value of simplify_and_or_mask() and let's do the second call if no simplifications could be done in the first one. For example, code like: int foo(int x, int y, int a) { return ((a & 0xf000) | (x & y)) & 0x0fff; } was expectedly simplified into: foo: and.32 %r5 <- %arg1, %arg2 and.32 %r7 <- %r5, $0xfff ret.32 %r7 while the same code with the operands of the OR swapped was not: int foo(int x, int y, int a) { return ((x & y) | (a & 0xf000)) & 0x0fff; } resulted in the non-optimized: foo: and.32 %r3 <- %arg1, %arg2 and.32 %r5 <- %arg3, $0xf000 or.32 %r6 <- %r3, %r5 and.32 %r7 <- %r6, $0xfff ret.32 %r7 but now the simplification can also be done: foo: and.32 %r3 <- %arg1, %arg2 and.32 %r7 <- %r3, $0xfff ret.32 %r7 Note: it would be simpler to unconditionally do both calls but this is unsafe because some of the concerned instructions, needed in the second call, could have been simplified away in the first one. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>