Displaying 5 results from an estimated 5 matches for "sdadsda".
Did you mean:
dasda
2010 Nov 20
3
[LLVMdev] Poor floating point optimizations?
On Nov 20, 2010, at 2:41 PM, Sdadsda Sdasdaas wrote:
> And also the resulting assembly code is very poor:
>
> 00460013 movss xmm0,dword ptr [esp+8]
> 00460019 movaps xmm1,xmm0
> 0046001C addss xmm1,xmm1
> 00460020 pxor xmm2,xmm2
> 00460024 addss xmm2,xmm1
> 00460028 ad...
2010 Nov 20
2
[LLVMdev] Poor floating point optimizations?
I wanted to use LLVM for my math parser but it seems that floating point
optimizations are poor.
For example consider such C code:
float foo(float x) { return x+x+x; }
and here is the code generated with "optimized" live demo:
define float @foo(float %x) nounwind readnone { entry: %0 = fmul float %x,
2.000000e+00 ; <float> [#uses=1] %1 = fadd float %0, %x
2010 Nov 20
0
[LLVMdev] Poor floating point optimizations?
And also the resulting assembly code is very poor:
00460013 movss xmm0,dword ptr [esp+8]
00460019 movaps xmm1,xmm0
0046001C addss xmm1,xmm1
00460020 pxor xmm2,xmm2
00460024 addss xmm2,xmm1
00460028 addss xmm2,xmm0
0046002C movss dword ptr [esp],xmm2
00460031 fld dword ptr [esp]
Especially pxor&and instead of movss (which is
2010 Nov 21
0
[LLVMdev] Poor floating point optimizations?
Thanks for replying so fast. This UnsafeFPMath trick in fact solves "pxor adds"
case, but the resulting code is still not as good as I expected from LLVM.
For example expressions like "1+x+1+x+1+x+1+x" (basically adding a lot of
constants and variables) are complied to a long series off <add>s both in IR
and
assembly code.
Both GCC and MSVC generates C1*x +C2 (mov +
2010 Nov 21
0
[LLVMdev] Poor floating point optimizations?
I'm aware that there are IEEE requirements for floating point. But all C/C++
compilers like GCC or MSVC have unsafe/fast math switches that disable all
problems related to NaN/Inf/+-0/precision etc because in some applications those
are not as important as performance (for example graphics calculation).
But as I understand, LLVM currently does not have such unsafe/fast math
optimizations