[PATCH] D37467: Add a new pass to speculate around PHI nodes with constant (integer) operands when profitable.

Thomas Preud'homme via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri May 28 08:45:20 PDT 2021


thopre added a comment.
Herald added subscribers: pengfei, steven_wu.
Herald added a project: LLVM.

@chandlerc

This pass does not seem to account for the extra branch instruction (1 for exiting the loop, 1 for looping back Vs 1 single branch when there's no critical edge) nor does it account for critical edge preventing the use of hardware loop instruction. The example that causes us trouble is:

  unsigned KnownDec(unsigned *arr) {
    unsigned x = 0x2000;
    unsigned z = 0;
    while(x) {
      z += arr[x-1];
      x--;
    }
    return z;
  }

When compiling for our (non-upstream) target, when get the following IR after this pass:

  entry:
    %sub.0 = add nsw i32 2000, -1
    br label %while.body
  
  while.body:                                       ; preds = %while.body.while.body_crit_edge, %entry
    %z.07 = phi i32 [ 0, %entry ], [ %add, %while.body.while.body_crit_edge ]
    %sub.phi = phi i32 [ %sub.0, %entry ], [ %sub.1, %while.body.while.body_crit_edge ]
    %arrayidx = getelementptr inbounds i32, i32* %arr, i32 %sub.phi
    %0 = load i32, i32* %arrayidx, align 4, !tbaa !2
    %add = add i32 %0, %z.07
    %tobool.not = icmp eq i32 %sub.phi, 0
    br i1 %tobool.not, label %while.end, label %while.body.while.body_crit_edge, !llvm.loop !6
  
  while.body.while.body_crit_edge:                  ; preds = %while.body
    %sub.1 = add nsw i32 %sub.phi, -1
    br label %while.body
  
  while.end:                                        ; preds = %while.body
    ret i32 %add

The fact that the condition check is separate from the loop latch means we cannot use a hardware loop instruction. Similar code gets generated for PowerPC if using 0x10000 instead of 2000 but they run EarlyCSE after which sink the value down again in the PHI and by chance they have a pass to canonicalize the loop form for their addressing mode which remove the getelementptr in the critical edge (inserted there by the loop strength reduction pass). This feels kinda lucky (the EarlyCSE and ppc-loop-instr-form-prep passes were added to the PPC pipeline long before the PHI speculation one. Is the expectation that targets with hardware loop deal with the result of PHI speculation? If that's the case, could we have a hook for those target to disable the pass when they suspect a hardware loop instruction might be used?

Best regards.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D37467/new/

https://reviews.llvm.org/D37467



More information about the llvm-commits mailing list