This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Predictive commoning leads to register to register moves through memory.


I've since taken another look at this recently and I've tracked the issue down to
tree-predcom.c, specifically ref_at_iteration almost always generating MEM_REFs.
With MEM_REFs, GCC's RTL GCSE cannot compare them as equal and hence 
remove them. A previous version of the code did generate ARRAY_REFs 
(pre 204458), but that was changed to generate MEM_REFs for pr/58653. 

Would something like:
--- a/gcc/tree-predcom.c
+++ b/gcc/tree-predcom.c
@@ -1409,7 +1409,21 @@ ref_at_iteration (data_reference_p dr, int iter, gimple_seq *stmts)
                             addr, alias_ptr),
                     DECL_SIZE (field), bitsize_zero_node);
     }
-  else
+  /* Generate an ARRAY_REF for array references when all details are INTEGER_CST
+     rather than a MEM_REF so that CSE passes can potientially optimize them.  */
+  else if (TREE_CODE (DR_REF (dr)) == ARRAY_REF
+          && TREE_CODE (DR_STEP (dr)) == INTEGER_CST
+          && TREE_CODE (DR_INIT (dr)) == INTEGER_CST
+          && TREE_CODE (DR_OFFSET (dr)) == INTEGER_CST)
+    {
+       /* Reverse engineer the element from memory offset.  */
+       tree offset = size_binop (MINUS_EXPR, coff, off);
+       tree sizdiv = TYPE_SIZE (TREE_TYPE (TREE_TYPE (DR_BASE_OBJECT (dr))));
+       sizdiv = div_if_zero_remainder (EXACT_DIV_EXPR, sizdiv, ssize_int (BITS_PER_UNIT));
+       tree element = div_if_zero_remainder (EXACT_DIV_EXPR, offset, sizdiv);
+       if (element != NULL_TREE)
+         return build4 (ARRAY_REF, TREE_TYPE (DR_REF (dr)), DR_BASE_OBJECT (dr),
+                        element, NULL_TREE, NULL_TREE);
+    }
     return fold_build2 (MEM_REF, TREE_TYPE (DR_REF (dr)), addr, alias_ptr);

be an appropriate start to fixing this? That fix appears to work in in my testing.

Thanks,
Simon

-----Original Message-----
From: Richard Biener [mailto:richard.guenther@gmail.com] 
Sent: 31 August 2015 11:40
To: Jeff Law
Cc: Simon Dardis; gcc@gcc.gnu.org
Subject: Re: Predictive commoning leads to register to register moves through memory.

On Fri, Aug 28, 2015 at 5:48 PM, Jeff Law <law@redhat.com> wrote:
> On 08/28/2015 09:43 AM, Simon Dardis wrote:
>
>> Following Jeff's advice[1] to extract more information from GCC, I've 
>> narrowed the cause down to the predictive commoning pass inserting 
>> the load in a loop header style basic block. However, the next pass 
>> in GCC, tree-cunroll promptly removes the loop and joins the loop 
>> header to the body of the (non)loop. More oddly, disabling 
>> conditional store elimination pass or the dominator optimizations 
>> pass or disabling of jump-threading with --param
>> max-jump-thread-duplication-stmts=0 nets the above assembly code. Any 
>> ideas on an approach for this issue?
>
> I'd probably start by looking at the .optimized tree dump in both 
> cases to understand the difference, then (most liklely) tracing that 
> through the RTL optimizers into the register allocator.

It's the known issue of LIM (here the one after pcom and complete unrolling of the inner loop) being too aggressive with store-motion.  Here the comptete array is replaced with registers for the outer loop.  Were 'poly' a local variable we'd have optimized it away completely.

  <bb 6>:
  _8 = 1.0e+0 / pretmp_42;
  _12 = _8 * _8;
  poly[1] = _12;

  <bb 7>:
  # prephitmp_30 = PHI <_12(6), _36(9)>
  # T_lsm.8_22 = PHI <_8(6), pretmp_42(9)>
  poly_I_lsm0.10_38 = MEM[(double *)&poly + 8B];
  _2 = prephitmp_30 * poly_I_lsm0.10_38;
  _54 = _2 * poly_I_lsm0.10_38;
  _67 = poly_I_lsm0.10_38 * _54;
  _80 = poly_I_lsm0.10_38 * _67;
  _93 = poly_I_lsm0.10_38 * _80;
  _106 = poly_I_lsm0.10_38 * _93;
  _19 = poly_I_lsm0.10_38 * _106;
  count_23 = count_28 + 1;
  if (count_23 != iterations_6(D))
    goto <bb 5>;
  else
    goto <bb 8>;

  <bb 8>:
  poly[2] = _2;
  poly[3] = _54;
  poly[4] = _67;
  poly[5] = _80;
  poly[6] = _93;
  poly[7] = _106;
  poly[8] = _19;
  i1 = 9;
  T = T_lsm.8_22;

note that DOM misses to CSE poly[1] (a known defect), but heh, doing that would only increase register pressure even more.

Note the above is on x86_64.

Richard.


> jeff

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]