This change effectively just reverts r195496, and updates the tests as needed.
8 and 16 bit compares no longer promoted up into 32 bit compares. This has some
nice performance improvements, especially in eembc/rgbcmykv2. In order for this
not to cause performance regressions in 401.bzip2, changes http://reviews.llvm.org/D21085
are also necessary to get all the necessary movb and movw instructions promoted to
movzbl/movzwl.
Details
Diff Detail
Event Timeline
test/CodeGen/X86/memcmp.ll | ||
---|---|---|
44 | 16-bit immediate operands are bad for performance on modern x86. |
test/CodeGen/X86/memcmp.ll | ||
---|---|---|
44 | I'm looking into changing the code so that 16 bit compares which have a constant operand will continue to get promoted, and how that affects the performance numbers. |
Updated changes so this will continue to promote 16 bit compares to 32 bits if one of the compare
operands is a constant. This addresses Eli Friedman's comment.
Yes, 16bit immediate constant may introduce LCP that may end up hurting performance. But on newer architectures (sandybridge and later), this problem is much less severe, especially when the loop body fits in LSD. I don't think it's a good idea to blindly convert all 16bit immediate constant comparison to 32bit.
16-bit immediate operands are bad for performance on modern x86.