[PATCH] [X86] Updates to X86 backend for f16 promotion

[Pirama Arumuga Nainar]

================
Comment at: test/CodeGen/X86/half.ll:103
@@ +102,3 @@
+; CHECK-LIBCALL: cvttss2si
+; CHECK-LIBCALL: cvttss2si
+; CHECK-FP16: vcvtph2ps
----------------
The uitofp generates two cvttss2si instructions along with a bunch of other instructions.  I don't really understand what's going.  Here's the exact sequence for '-f16c':

        .cfi_def_cfa_offset 16
        movzwl  (%rdi), %edi
        callq   __gnu_h2f_ieee
        movss   .LCPI9_0(%rip), %xmm1   # xmm1 = mem[0],zero,zero,zero
        movaps  %xmm0, %xmm2
        subss   %xmm1, %xmm2
        cvttss2si       %xmm2, %rax
        movabsq $-9223372036854775808, %rcx # imm = 0x8000000000000000
        xorq    %rax, %rcx
        cvttss2si       %xmm0, %rax
        ucomiss %xmm1, %xmm0
        cmovaeq %rcx, %rax
        popq    %rdx
        retq

If you think this is optimal, I'll add CHECKs for the movabs, xor etc.

================
Comment at: test/CodeGen/X86/half.ll:157
@@ +156,3 @@
+; CHECK: callq  __truncdfhf2
+  %v = fptrunc <4 x double> %a to <4 x half>
+  store <4 x half> %v, <4 x half>* %p
----------------
delena wrote:
> Why double to half can't go through the chain (double -> float ->half). I'm just asking..
A chained conversion through float is done if unsafe math is enabled (See around line 3458 in lib/CodeGen/SelectionDAG/LegalizeDAG.cpp).  Interestingly, half -> double goes through an intermediate float (this is done in the 'case ISD::FP16_TO_FP' just above.

I am not sure why double -> float -> half is considered a precision loss, while the reverse chain isn't.

http://reviews.llvm.org/D9092

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/