maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

move PR1264 here. 

llvm-svn: 42345
This commit is contained in:
Chris Lattner 2007-09-26 06:15:48 +00:00
parent d0382a8550
commit fef69f5b4a
1 changed files with 28 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
llvm/lib/Target/X86/README-SSE.txt
View File

@ -631,7 +631,7 @@ _bar:
//===---------------------------------------------------------------------===//
We should materialize vecetor constants like "all ones" and "signbit" with
We should materialize vector constants like "all ones" and "signbit" with
code like:
cmpeqps xmm1, xmm1 ; xmm1 = all-ones
@ -644,3 +644,30 @@ instead of using a load from the constant pool. The later is important for
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.
//===---------------------------------------------------------------------===//