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?

2018-02-23  Wilco Dijkstra  <>

        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
--- 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