http://llvm.org/bugs/show_bug.cgi?id=16776
Bug ID: 16776
Summary: Instcombine transformation causes poor vector codegen
[SSE4]
Product: new-bugs
Version: trunk
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Classification: Unclassified
Created attachment 10973
--> http://llvm.org/bugs/attachment.cgi?id=10973&action=edit
test case
The attached test case does a vector compare of a <16 x i8> value with zero and
then a vector select based on the comparison to negate elements that are less
than zero (i.e. computes the absolute value). If I run it through llc as is, a
single glorious PABSB instruction is generated:
pabsb %xmm0, %xmm0
However, if I run "opt -instcombine bug2.ll | llc -o -", I get a 13 instruction
sequence instead of the PABSB:
movdqa %xmm0, %xmm1
pxor %xmm2, %xmm2
movdqa %xmm1, %xmm3
psrlw $7, %xmm3
movdqa LCPI0_0(%rip), %xmm0
pand %xmm0, %xmm3
pand %xmm0, %xmm3
pcmpeqb %xmm2, %xmm3
psubb %xmm1, %xmm2
pcmpeqd %xmm0, %xmm0
pxor %xmm3, %xmm0
pblendvb %xmm2, %xmm1
movdqa %xmm1, %xmm0
What seems to be happening is that the "vector (x <s 0) ? -1 : 0 -> ashr x, 31
-> all ones if signed." test at the end of InstCombiner::transformSExtICmp()
is kicking in, which in turn leads to the "< 0" test being transformed into a
lshr of 7 and an 'and' of the low bit, which in turn doesn't hit the PABSB
pattern in the X86 code generator.
Interestingly enough, the IR code triggering this transformation is dead code;
if I run "opt -dce -instcombine bug2.ll", then I again get the single PABSB.
As such, it looks like I can work around this by always running DCE before
InstCombine, but that seems like it may just be plastering over the underlying
issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
