Vector{128|256}<T> == Vector{128|256}<T> could emit PXOR + PTEST combo on x86

[gfoidl]

bool Foo(Vector128<byte> v1, Vector128<byte> v2) => v1 == v2;

emits on x86:

vzeroupper
vmovupd xmm0, [rdx]
vpcmpeqb xmm0, xmm0, [r8]
vpmovmskb eax, xmm0
cmp eax, 0xffff
sete al
movzx eax, al
ret

So a vpcmpeqb + vpmovmskb + cmp. For SSE4.1 -- where ptest is available -- this could emit instead:

vzeroupper
vmovupd xmm0, [rdx]
-vpcmpeqb xmm0, xmm0, [r8]
-vpmovmskb eax, xmm0
-cmp eax, 0xffff
+vpxor xmm0, xmm0, [r8]
+vptest xmm0, xmm0
sete al
movzx eax, al
ret

So a vpxor + vptest. This codegen can be achieved by writing the method as

bool Foo(Vector128<byte> v1, Vector128<byte> v2) => (v1 ^ v2) == Vector128<byte>.Zero;

but this is unhandy (especially when there's a nice operator for it).

According Testing equality between two __m128i variables (especially in the comments) it's hard to benchmark which version is faster, but the vpxor + vptest combo may be faster on cpus where vpxor can run on more ports.
Another point is that the code-size shrinks (a bit).

Is it worth to change the codegen here?

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

bool Foo(Vector128<byte> v1, Vector128<byte> v2) => v1 == v2;

emits on x86:

vzeroupper
vmovupd xmm0, [rdx]
vpcmpeqb xmm0, xmm0, [r8]
vpmovmskb eax, xmm0
cmp eax, 0xffff
sete al
movzx eax, al
ret

So a vpcmpeqb + vpmovmskb + cmp. For SSE4.1 -- where ptest is available -- this could emit instead:

vzeroupper
vmovupd xmm0, [rdx]
-vpcmpeqb xmm0, xmm0, [r8]
-vpmovmskb eax, xmm0
-cmp eax, 0xffff
+vpxor xmm0, xmm0, [r8]
+vptest xmm0, xmm0
sete al
movzx eax, al
ret

So a vpxor + vptest. This codegen can be achieved by writing the method as

bool Foo(Vector128<byte> v1, Vector128<byte> v2) => (v1 ^ v2) == Vector128<byte>.Zero;

but this is unhandy (especially when there's a nice operator for it).

According Testing equality between two __m128i variables (especially in the comments) it's hard to benchmark which version is faster, but the vpxor + vptest combo may be faster on cpus where vpxor can run on more ports.
Another point is that the code-size shrinks (a bit).

Is it worth to change the codegen here?

Author:	gfoidl
Assignees:	-
Labels:	area-CodeGen-coreclr, untriaged
Milestone:	-

[EgorBo]

Last time I did this I got regressions, see #67902

[gfoidl]

Ah, I was pretty sure you have tried this, but couldn't find the issue / PR for this. Thanks for the link!

So leave the codegen as is and close this issue?

[EgorBo]

Don't know, maybe with #85551 we can do this opt selectively

[tannergooding]

I don't think we want to get in the habit of chasing cycle level micro-architecture specific optimizations. That just increases complexity of our test matrix for little overall benefit. I think we want to focus #85551 around areas where there is a significant benefit to the difference, enough to warrant having the two code paths.

There are a few complexities here on why pxor, ptest is slower than pcmpeq, pmovmsk, cmp and its likely going to stay that way on avx512 where we can do pcmpeq, ktest instead and have the benefits of also using the output for masking or other more complex checks.

[JulieLeeMSFT]

Based on discussion, I am closing this issue. Please feel free to reopen when it is worthwhile to fix this.