[llvm] [DAG] Fixing the non-optimal code with the following: `select i1 %0, float 1.0, float 0.0`. (PR #107732)

[via llvm-commits]

================
@@ -1,12 +1,21 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --version 5
 ; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+avx512f -show-mc-encoding | FileCheck %s
 ; RUN: llc < %s -mtriple=x86_64-unknown -mattr=+avx512f,+egpr -show-mc-encoding | FileCheck --check-prefix=EGPR %s
 
 define void @kmov(i1 %cmp23.not) {
 ; CHECK-LABEL: kmov:
-; CHECK:       kmovw %edi, %k1 # encoding: [0xc5,0xf8,0x92,0xcf]
+; CHECK:       # %bb.0: # %entry
+; CHECK-NEXT:    andl $1, %edi # encoding: [0x83,0xe7,0x01]
+; CHECK-NEXT:    vcvtsi2sd %edi, %xmm0, %xmm0 # EVEX TO VEX Compression encoding: [0xc5,0xfb,0x2a,0xc7]
+; CHECK-NEXT:    vmovsd %xmm0, 0 # EVEX TO VEX Compression encoding: [0xc5,0xfb,0x11,0x04,0x25,0x00,0x00,0x00,0x00]
+; CHECK-NEXT:    retq # encoding: [0xc3]
 ;
 ; EGPR-LABEL: kmov:
-; EGPR:       kmovw %edi, %k1 # EVEX TO VEX Compression encoding: [0xc5,0xf8,0x92,0xcf]
+; EGPR:       # %bb.0: # %entry
+; EGPR-NEXT:    andl $1, %edi # encoding: [0x83,0xe7,0x01]
+; EGPR-NEXT:    vcvtsi2sd %edi, %xmm0, %xmm0 # EVEX TO VEX Compression encoding: [0xc5,0xfb,0x2a,0xc7]
+; EGPR-NEXT:    vmovsd %xmm0, 0 # EVEX TO VEX Compression encoding: [0xc5,0xfb,0x11,0x04,0x25,0x00,0x00,0x00,0x00]
+; EGPR-NEXT:    retq # encoding: [0xc3]
 entry:
   %0 = select i1 %cmp23.not, double 1.000000e+00, double 0.000000e+00
----------------
c8ef wrote:

I did not write this test case, so I'm not sure why certain cases are not covered. The patch only handles the select 1, 0 case because I'm uncertain if the affected test cases exhibit any regression. If this approach is correct, I will add the select -1, 0 case.


https://github.com/llvm/llvm-project/pull/107732