diff options
author | agl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-03-16 18:46:32 +0000 |
---|---|---|
committer | agl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-03-16 18:46:32 +0000 |
commit | 12e0eed769a220d8ff490f092a7235af6f68270e (patch) | |
tree | 54b108ff8fc5f29838ed48c08e659b28c71c6f71 /chrome/plugin | |
parent | c0b99038c58d79f7c1032f35dfb0eb62279a2d0d (diff) | |
download | chromium_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