Contribution of PowerPC port (continuation of 422063005)

test/mjsunit/mjsunit.status

Index: test/mjsunit/mjsunit.status
diff --git a/test/mjsunit/mjsunit.status b/test/mjsunit/mjsunit.status
index ee03407fd3a2588403e62ae026ac9accae7e786a..2934d597f5796b8c7b6c49a7c8ee8f1db620a2e5 100644
--- a/test/mjsunit/mjsunit.status
+++ b/test/mjsunit/mjsunit.status
@@ -571,6 +571,14 @@
 }],  # 'arch == nacl_ia32 or arch == nacl_x64'
 
 ##############################################################################
+['arch == ppc or arch == ppc64', {
+
+  # Test does not handle increased precision of multiply-add optimization

[Sven Panne, 2015/01/08 10:13:53]

Huh? What is the exact problem here? No result should depend on the computation
being optimized or not, otherwise it's a bug.

[michael_dawson, 2015/01/08 23:51:11]

PPC has Floating-Point Multiply-Add Instructions which combine a multiply and an
add operation without an intermediate rounding operation.  We used these
instructions in some cases as an optimization to use 1 instruction instead of 2
but the result is that there is as small difference in the end result in some
cases as you avoid the intermediate rounding.  At the time we thought this would
be ok but I can see that the spec could prohibit this kind of optimization so
that you always get precisely the same result.  Since it sounds like that is the
case I can remove this change and we'll remove the optimization when we bring
the contents of the ppc specific directories up to date 

[Jakob Kummerow, 2015/01/09 11:36:05]

Drive-by: The reason we want optimization not to affect computation results is
that typically, a function will run as unoptimized code for a while, and then
get optimized when it's hot, and potentially get deoptimized later. It would be
very surprising if this caused computation results for the same inputs to
randomly change during program execution.

Similar issues have hit us before, e.g. on ia32 where the C++ compiler might use
the 80-bit FPU for arithmetic operations in runtime functions called from
unoptimized code, whereas hand-written assembly in optimized code would use the
SSE unit (with 64 bits of precision). The solution is to ensure that the same
precision is used in all cases.

In some cases this is doable (this is why we have e.g. CreateSqrtFunction() in
codegen-<arch>.cc), but in others it could mean that you just can't do certain
optimizations (FMA sounds like an example of this, if it depends on the
optimizing compiler detecting matching instruction patterns in user-supplied
functions).

+  'numops-fuzz-part2': [PASS, FAIL]
+
+}],  # 'arch == ppc or arch == ppc64'
+
+##############################################################################
 ['deopt_fuzzer == True', {
 
   # Skip tests that are not suitable for deoptimization fuzzing.