[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