As discussed in the PR, the reassociation phase runs before FMAs are formed
and so can significantly reduce FMA opportunities.  Although reassociation
could be switched off, it helps in many cases, so a better alternative is to
only avoid reassociation of floating point additions.  This fixes the testcase
and gives 1% speedup on SPECFP2017, fixing the performance regression.

OK for commit?

ChangeLog:
2018-02-23  Wilco Dijkstra  <wdijk...@arm.com>

        PR tree-optimization/84114
        * config/aarch64/aarch64.c (aarch64_reassociation_width)
        Avoid reassociation of FLOAT_MODE addition.
--

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 
b3d5fde171920e5759046a4bd61cfcf9eb78d7dd..5f9541cf700aaf18c1f1ac73054614e2932781e4
 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1109,15 +1109,16 @@ aarch64_min_divisions_for_recip_mul (machine_mode mode)
   return aarch64_tune_params.min_div_recip_mul_df;
 }
 
+/* Return the reassociation width of treeop OPC with mode MODE.  */
 static int
-aarch64_reassociation_width (unsigned opc ATTRIBUTE_UNUSED,
-                            machine_mode mode)
+aarch64_reassociation_width (unsigned opc, machine_mode mode)
 {
   if (VECTOR_MODE_P (mode))
     return aarch64_tune_params.vec_reassoc_width;
   if (INTEGRAL_MODE_P (mode))
     return aarch64_tune_params.int_reassoc_width;
-  if (FLOAT_MODE_P (mode))
+  /* Avoid reassociating floating point addition so we emit more FMAs.  */
+  if (FLOAT_MODE_P (mode) && opc != PLUS_EXPR)
     return aarch64_tune_params.fp_reassoc_width;
   return 1;
 }

Reply via email to