[PATCH] D55866: [DAGCombiner] allow narrowing of add followed by truncate

Andrea Di Biagio via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 19 03:24:19 PST 2018


andreadb added inline comments.


================
Comment at: test/CodeGen/X86/pr32345.ll:122-126
 ; 686-NEXT:    movzwl var_27, %ecx
-; 686-NEXT:    movl %ecx, %edx
-; 686-NEXT:    xorl %ecx, %edx
-; 686-NEXT:    xorl %eax, %edx
-; 686-NEXT:    movzwl %dx, %eax
+; 686-NEXT:    movzwl var_22, %eax
+; 686-NEXT:    xorw %cx, %ax
+; 686-NEXT:    xorl %ecx, %eax
+; 686-NEXT:    movzwl %ax, %eax
----------------
Not sure what is going on here..

We fail to realize that XOR is both commutative and associative.
We are essentially doing `(%eax XOR %ecx) XOR %ecx`.
That is equivalent to `%eax XOR (%ecx XOR %ecx)`. The second XOR is a zero-idiom.
So, it becomes `%eax XOR 0`, which is %eax.

That entire computation could be folded away.

We should generate just this:
```
movzwl var_27, %ecx
movzwl var_22, %eax
```

As a side note: we even fail to realize that the last zero-extending move is redundant! The upper half of EAX is already zero, because it already comes from a zero-extending move. The XOR is done with ECX, which also is zero-extended! So, the upper bits cannot possibly be anything else other than zero.
So, the zero-extending move is completely redundant here, because the result is already zero.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55866/new/

https://reviews.llvm.org/D55866





More information about the llvm-commits mailing list