trunc (add X, C ) --> add (trunc X), C'
If we're throwing away the top bits of an 'add' instruction, do it in the narrow destination type.
This makes the truncate-able opcode list identical to the sibling transform done in IR (in instcombine).
This change used to show regressions for x86, but those are gone after D55494. This gets us closer to deleting the x86 custom function (combineTruncatedArithmetic) that does almost the same thing.
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:
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.