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
Diff Detail
- Repository
- rL LLVM
Event Timeline
Looks good to me.
test/CodeGen/X86/known-bits-vector.ll | ||
---|---|---|
8–11 | 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 | 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. |
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:
In this case, we could avoid to move data back and forth from the integer unit to the floating point unit.