summaryrefslogtreecommitdiffstats
path: root/chrome/plugin
diff options
context:
space:
mode:
authoragl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-03-16 18:46:32 +0000
committeragl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-03-16 18:46:32 +0000
commit12e0eed769a220d8ff490f092a7235af6f68270e (patch)
tree54b108ff8fc5f29838ed48c08e659b28c71c6f71 /chrome/plugin
parentc0b99038c58d79f7c1032f35dfb0eb62279a2d0d (diff)
downloadchromium_src-12e0eed769a220d8ff490f092a7235af6f68270e.zip
chromium_src-12e0eed769a220d8ff490f092a7235af6f68270e.tar.gz
chromium_src-12e0eed769a220d8ff490f092a7235af6f68270e.tar.bz2
Linux: Use -mfpmath=sse to remove differences between opt and debug
(note: this change now requires a P4 to build. It's easy to back it out for older processors, but they shouldn't be used to run layout-tests.) We are seeing issues where the opt build ends up with very slightly different colours in layout tests than the debug build. This is probably due to floating point rounding differences. All floating-point computations on x87 happens in 80-bit precision. Because the C and C++ language standards allow the compiler to keep the floating-point values in higher precision than what's specified in the source and doing so is more efficient than constantly rounding up to 64-bit or 32-bit precision as specified in the source, the compiler, especially in the optimized mode, tries very hard to keep values in x87 floating-point stack (in 80-bit precision) as long as possible. This has important side effects, that the real value used in computation may change depending on how the compiler did the optimization - that is, the value kept in 80-bit is different than the value rounded down to 64-bit or 32-bit. There are possible compiler options to make this behavior consistent (e.g. -ffloat-store would keep all floating-values in the memory, thus force them to be rounded to its original precision) but they have significant runtime performance penalty. -mfpmath=sse -msse2 makes the compiler use SSE instructions which keep floating-point values in SSE registers in its native precision (32-bit for single precision, and 64-bit for double precision values). This means the floating-point value used during computation does not change depending on how the compiler optimized the code, since the value is always kept in its specified precision. Internal performace tests of these options shows that it's not a clear performance win or loss across the board. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11751 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/plugin')
0 files changed, 0 insertions, 0 deletions