lvqcl
2014-Mar-22 08:17 UTC
[flac-dev] About "attempt to fix differences between x86 FPU and SSE calculations"
Olivier Tristan <o.tristan at uvi.net> ?????(?) ? ????? ?????? Fri, 21 Mar 2014 22:41:00 +0400:> Check with -mfpmath=387 to be sure that x87 FPU code is used and not some > SSE optim made by GCCI added "XIPH_ADD_CFLAGS([-mfpmath=387])" into configure.ac Still the result is different from SSE version. --------------- MSVS adds two instructions to the generated code after the patch: fld DWORD PTR [eax] inc ecx fmul ST(0), ST(1) add eax, 4 fstp DWORD PTR tv2337[esp+20] <- this: (copy from FP stack to tmp) fld DWORD PTR tv2337[esp+20] <- and this (copy from tmp to FP stack) fadd DWORD PTR [ebx+ecx*4-4] fstp DWORD PTR [ebx+ecx*4-4] However GCC doesn't do this: lea ecx, [eax+2] fld DWORD PTR [edx+ecx*4] fmul st, st(1) fadd DWORD PTR [ebx+ecx*4] fstp DWORD PTR [ebx+ecx*4] Also MSVS doesn't add these instructions if Floating Point Model is set to Fast (/fp:fast).
Martijn van Beurden
2014-Mar-22 08:34 UTC
[flac-dev] About "attempt to fix differences between x86 FPU and SSE calculations"
op 22-03-14 09:17, lvqcl schreef:> I added "XIPH_ADD_CFLAGS([-mfpmath=387])" into configure.ac > Still the result is different from SSE version.Maybe it should be left alone. The difference is not really harmful (aside from the people wondering who might think it is a serious bug), it has been documented in the FAQ for years and 'solving' this is probably going to be a wild goose chase. I think this is not worth the added code complexity.
Erik de Castro Lopo
2014-Mar-22 10:24 UTC
[flac-dev] About "attempt to fix differences between x86 FPU and SSE calculations"
Martijn van Beurden wrote:> op 22-03-14 09:17, lvqcl schreef: > > I added "XIPH_ADD_CFLAGS([-mfpmath=387])" into configure.ac > > Still the result is different from SSE version. > > Maybe it should be left alone. The difference is not really > harmful (aside from the people wondering who might think it is a > serious bug), it has been documented in the FAQ for years and > 'solving' this is probably going to be a wild goose chase. > > I think this is not worth the added code complexity.I agree. Unless anyone can some up with a good reason for it to stay, I'm going to revert this patch tomorrow. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/