If either of the operand elements are zero then we know the result element is going to be zero (even if the other element is undef).
Details
Details
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
Comment Actions
Looks good to me.
test/CodeGen/X86/known-bits-vector.ll | ||
---|---|---|
8–11 ↗ | (On Diff #177707) | Unrelated to this patch: If we know that only element 0 is goign to be used, then - in this case - it is better to move the computation in the Integer unit. Something like: vpextrw $0, %xmm0, %eax and $15, %eax In this case, we could avoid to move data back and forth from the integer unit to the floating point unit. |
test/CodeGen/X86/known-signbits-vector.ll | ||
280–283 ↗ | (On Diff #177707) | Similar problem. However, this time we can keep the computation in the FP unit, and avoid data to be bounced back and forth from the two units. vmovq %rax, %xmm1 vpand %xmm1, %xmm0, %xmm0 vcvtdq2ps %xmm0, %xmm0 That being said, I suspect that this code can be further simplified (as in: scalarized) if we keep improving the knowledge about demanded vector elements. |