Contribution of PowerPC port (continuation of 422063005)

test/mjsunit/mjsunit.status

 # Copyright 2012 the V8 project authors. All rights reserved.
 # Redistribution and use in source and binary forms, with or without
 # modification, are permitted provided that the following conditions are
 # met:
 #
 #     * Redistributions of source code must retain the above copyright
 #       notice, this list of conditions and the following disclaimer.
 #     * Redistributions in binary form must reproduce the above
 #       copyright notice, this list of conditions and the following
 #       disclaimer in the documentation and/or other materials provided
@@ skipping 553 matching lines @@
 
   # Lead to OOM:
   'string-oom-*': [SKIP],
 
   # Crashes.
   'harmony/private': [SKIP],
   'harmony/symbols': [SKIP],
 }],  # '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.
   'assert-opt-and-deopt': [SKIP],
   'never-optimize': [SKIP],
   'regress/regress-2185-2': [SKIP],
   'harmony/object-observe': [SKIP],
   'readonly': [SKIP],
   'array-feedback': [SKIP],
 
   # Deopt every n garbage collections collides with deopt every n times.
   'regress/regress-2653': [SKIP],
 }],  # 'deopt_fuzzer == True'
 ]