[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:

Although the code generation is correct, the original test case was meant to test the kmov instruction. However, with this patch, we did not generate the corresponding instruction at all. Is this the intended behavior?

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