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

[Shengchen Kan 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
----------------
KanRobert wrote:

No, it not intended. The test is important for checking EGPR support for KMOV.  If we think the generated code is better in this test, we should  update the IR to generate kmov.

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