From 4d93b2f16d66841f3338ffe2c1318fe6eeeef181 Mon Sep 17 00:00:00 2001 From: Chris Lattner Date: Wed, 5 Mar 2008 17:11:51 +0000 Subject: [PATCH] evan implemented this. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@47948 91177308-0d34-0410-b5e6-96231b3b80d8 --- lib/Target/X86/README-SSE.txt | 26 -------------------------- 1 file changed, 26 deletions(-) diff --git a/lib/Target/X86/README-SSE.txt b/lib/Target/X86/README-SSE.txt index 7248a57df32..7f4a707c30f 100644 --- a/lib/Target/X86/README-SSE.txt +++ b/lib/Target/X86/README-SSE.txt @@ -586,32 +586,6 @@ ABS/NEG/copysign etc. //===---------------------------------------------------------------------===// -"converting 64-bit constant pool entry to 32-bit not necessarily beneficial" -http://llvm.org/PR1264 - -For this test case: - -define double @foo(double %x) { - %y = mul double %x, 5.000000e-01 - ret double %y -} - -llc -march=x86-64 currently produces a 32-bit constant pool entry and this code: - - cvtss2sd .LCPI1_0(%rip), %xmm1 - mulsd %xmm1, %xmm0 - -instead of just using a 64-bit constant pool entry with this: - - mulsd .LCPI1_0(%rip), %xmm0 - -This is due to the code in ExpandConstantFP in LegalizeDAG.cpp. It notices that -x86-64 indeed has an instruction to load a 32-bit float from memory and convert -it into a 64-bit float in a register, however it doesn't notice that this isn't -beneficial because it prevents the load from being folded into the multiply. - -//===---------------------------------------------------------------------===// - These functions: #include -- 2.34.1