Expand comment for HVecMultiplyAccumulate

State explicitly that fused multiply-add may not be used, since this
was a source of prior confusion. Add a DCHECK to draw developers
attention to this, if they try to add a floating point multiply-add.

See https://android-review.googlesource.com/c/platform/art/+/716505 .

Test: Treehugger
Change-Id: I1331be120a0a54baeb4da92e9211407b08892e98

1 files changed, 6 insertions, 0 deletions

diff --git a/compiler/optimizing/nodes_vector.h b/compiler/optimizing/nodes_vector.h
index c5e9a8d036..95fb5ab76a 100644
--- a/compiler/optimizing/nodes_vector.h
+++ b/compiler/optimizing/nodes_vector.h
@@ -931,6 +931,9 @@ class HVecSetScalars FINAL : public HVecOperation {
 
 // Multiplies every component in the two vectors, adds the result vector to the accumulator vector,
 // viz. [ a1, .. , an ] + [ x1, .. , xn ] * [ y1, .. , yn ] = [ a1 + x1 * y1, .. , an + xn * yn ].
+// For floating point types, Java rounding behavior must be preserved; the products are rounded to
+// the proper precision before being added. "Fused" multiply-add operations available on several
+// architectures are not usable since they would violate Java language rules.
 class HVecMultiplyAccumulate FINAL : public HVecOperation {
  public:
   HVecMultiplyAccumulate(ArenaAllocator* allocator,
@@ -953,6 +956,9 @@ class HVecMultiplyAccumulate FINAL : public HVecOperation {
     DCHECK(HasConsistentPackedTypes(accumulator, packed_type));
     DCHECK(HasConsistentPackedTypes(mul_left, packed_type));
     DCHECK(HasConsistentPackedTypes(mul_right, packed_type));
+    // Remove the following if we add an architecture that supports floating point multiply-add
+    // with Java-compatible rounding.
+    DCHECK(DataType::IsIntegralType(packed_type));
     SetRawInputAt(0, accumulator);
     SetRawInputAt(1, mul_left);
     SetRawInputAt(2, mul_right);