[X86] Poor codegen for SSE ((x == 1) || (x == 2))

[RKSimon]

https://godbolt.org/z/KT5fxKjbG

#include <x86intrin.h>
__m128i cmp1OR2_epi32(__m128i x) {
    __m128i is1 = _mm_cmpeq_epi32(x, _mm_set1_epi32(1));
    __m128i is2 = _mm_cmpeq_epi32(x, _mm_set1_epi32(2));
    return _mm_or_si128(is1, is2);
}

I used 1 and 2, but it occurs with any 2 sequential constants.

Due to an InstCombine fold, instead of just comparing the 2 sequential values and ORing the result, we end up with:

define <2 x i64> @cmp1OR2_epi32(<2 x i64> noundef %x) {
entry:
  %0 = bitcast <2 x i64> %x to <4 x i32>
  %1 = add <4 x i32> %0, <i32 -1, i32 -1, i32 -1, i32 -1>
  %or.i89 = icmp ult <4 x i32> %1, <i32 2, i32 2, i32 2, i32 2>
  %or.i8 = sext <4 x i1> %or.i89 to <4 x i32>
  %or.i = bitcast <4 x i32> %or.i8 to <2 x i64>
  ret <2 x i64> %or.i
}

cmp1OR2_epi32:
  pcmpeqd %xmm1, %xmm1
  paddd %xmm1, %xmm0
  movdqa .LCPI2_0(%rip), %xmm1 # xmm1 = [1,1,1,1]
  pminud %xmm0, %xmm1
  pcmpeqd %xmm1, %xmm0
  retq

I could /almost/ accept this if it meant we reduced constant loads, but on pre-SSE4 targets we end up with:

cmp1OR2_epi32:
  pcmpeqd %xmm1, %xmm1
  paddd %xmm0, %xmm1
  pxor .LCPI2_0(%rip), %xmm1
  movdqa .LCPI2_1(%rip), %xmm0 # xmm0 = [2147483650,2147483650,2147483650,2147483650]
  pcmpgtd %xmm1, %xmm0
  retq

Untangling the icmp_ult(add(x,-1),2) (or the general solution) shouldn't be too difficult.

[llvmbot]

@llvm/issue-subscribers-backend-x86

https://godbolt.org/z/KT5fxKjbG ```c #include __m128i cmp1OR2_epi32(__m128i x) { __m128i is1 = _mm_cmpeq_epi32(x, _mm_set1_epi32(1)); __m128i is2 = _mm_cmpeq_epi32(x, _mm_set1_epi32(2)); return _mm_or_si128(is1, is2); } ``` I used 1 and 2, but it occurs with any 2 sequential constants.

Due to an InstCombine fold, instead of just comparing the 2 sequential values and ORing the result, we end up with:

define <2 x i64> @cmp1OR2_epi32(<2 x i64> noundef %x) {
entry:
  %0 = bitcast <2 x i64> %x to <4 x i32>
  %1 = add <4 x i32> %0, <i32 -1, i32 -1, i32 -1, i32 -1>
  %or.i89 = icmp ult <4 x i32> %1, <i32 2, i32 2, i32 2, i32 2>
  %or.i8 = sext <4 x i1> %or.i89 to <4 x i32>
  %or.i = bitcast <4 x i32> %or.i8 to <2 x i64>
  ret <2 x i64> %or.i
}

cmp1OR2_epi32:
  pcmpeqd %xmm1, %xmm1
  paddd %xmm1, %xmm0
  movdqa .LCPI2_0(%rip), %xmm1 # xmm1 = [1,1,1,1]
  pminud %xmm0, %xmm1
  pcmpeqd %xmm1, %xmm0
  retq

I could /almost/ accept this if it meant we reduced constant loads, but on pre-SSE4 targets we end up with:

cmp1OR2_epi32:
  pcmpeqd %xmm1, %xmm1
  paddd %xmm0, %xmm1
  pxor .LCPI2_0(%rip), %xmm1
  movdqa .LCPI2_1(%rip), %xmm0 # xmm0 = [2147483650,2147483650,2147483650,2147483650]
  pcmpgtd %xmm1, %xmm0
  retq

Untangling the icmp_ult(add(x,-1),2) (or the general solution) shouldn't be too difficult.

[RKSimon]

https://alive2.llvm.org/ce/z/adaTCb

----------------------------------------
define i1 @src(i8 %x, i8 %c) {
%0:
  %diff = add i8 %x, %c
  %res = icmp ult i8 %diff, 2
  ret i1 %res
}
=>
define i1 @tgt(i8 %x, i8 %c) {
%0:
  %c0 = sub i8 0, %c
  %c1 = sub i8 1, %c
  %x0 = icmp eq i8 %x, %c0
  %x1 = icmp eq i8 %x, %c1
  %res = or i1 %x0, %x1
  ret i1 %res
}
Transformation seems to be correct!

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. In the comments of the issue, request for it to be assigned to you.
2. Fix the issue locally.
3. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
4. Create a Git commit.
5. Run git clang-format HEAD~1 to format your changes.
6. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

Author: Simon Pilgrim (RKSimon)

https://godbolt.org/z/KT5fxKjbG ```c #include <x86intrin.h> __m128i cmp1OR2_epi32(__m128i x) { __m128i is1 = _mm_cmpeq_epi32(x, _mm_set1_epi32(1)); __m128i is2 = _mm_cmpeq_epi32(x, _mm_set1_epi32(2)); return _mm_or_si128(is1, is2); } ``` I used 1 and 2, but it occurs with any 2 sequential constants.

Due to an InstCombine fold, instead of just comparing the 2 sequential values and ORing the result, we end up with:

define &lt;2 x i64&gt; @<!-- -->cmp1OR2_epi32(&lt;2 x i64&gt; noundef %x) {
entry:
  %0 = bitcast &lt;2 x i64&gt; %x to &lt;4 x i32&gt;
  %1 = add &lt;4 x i32&gt; %0, &lt;i32 -1, i32 -1, i32 -1, i32 -1&gt;
  %or.i89 = icmp ult &lt;4 x i32&gt; %1, &lt;i32 2, i32 2, i32 2, i32 2&gt;
  %or.i8 = sext &lt;4 x i1&gt; %or.i89 to &lt;4 x i32&gt;
  %or.i = bitcast &lt;4 x i32&gt; %or.i8 to &lt;2 x i64&gt;
  ret &lt;2 x i64&gt; %or.i
}

cmp1OR2_epi32:
  pcmpeqd %xmm1, %xmm1
  paddd %xmm1, %xmm0
  movdqa .LCPI2_0(%rip), %xmm1 # xmm1 = [1,1,1,1]
  pminud %xmm0, %xmm1
  pcmpeqd %xmm1, %xmm0
  retq

I could /almost/ accept this if it meant we reduced constant loads, but on pre-SSE4 targets we end up with:

cmp1OR2_epi32:
  pcmpeqd %xmm1, %xmm1
  paddd %xmm0, %xmm1
  pxor .LCPI2_0(%rip), %xmm1
  movdqa .LCPI2_1(%rip), %xmm0 # xmm0 = [2147483650,2147483650,2147483650,2147483650]
  pcmpgtd %xmm1, %xmm0
  retq

Untangling the icmp_ult(add(x,-1),2) (or the general solution) shouldn't be too difficult.

[goldsteinn]

Would imagine this is true really for any pre-avx512 compares where we don't have an unsigned vec compare.

[RKSimon]

Yes, although the cmpeq+umin expansion might still be better.

[goldsteinn]

Fix: #84104