search for: sdasdaas

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 addss...

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

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

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 +

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