[PATCH] D58770: [LSR] Attempt to increase the accuracy of LSR's setup cost

Dave Green via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 28 03:11:16 PST 2019


dmgreen created this revision.
dmgreen added reviewers: kparzysz, bcahoon, samparker, qcolombet, gilr.
Herald added subscribers: jdoerfert, javed.absar, kristof.beyls.

In some loops, we end up generating loop induction variables that look like:
{(-1 * (zext i16 (%i0 * %i1) to i32))<nsw>,+,1}
As opposed to the simpler:
{(zext i16 (%i0 * %i1) to i32),+,-1}
i.e we count up from -limit to 0, not the simpler counting down from limit to 0. This is because the scores, as LSR calculates them, are the same and the second is filtered in place of the first. We end up with a redundant SUB from 0 in the code.

This patch tries to make the calculation of the setup cost a little more thorough, recursing into the scev members to better approximate the setup required.  The cost function for comparing LSR costs is:

  return std::tie(C1.NumRegs, C1.AddRecCost, C1.NumIVMuls, C1.NumBaseAdds,
                  C1.ScaleCost, C1.ImmCost, C1.SetupCost) <
         std::tie(C2.NumRegs, C2.AddRecCost, C2.NumIVMuls, C2.NumBaseAdds,
                  C2.ScaleCost, C2.ImmCost, C2.SetupCost);

So this will only alter results if none of the other variables turn out to be different.

I've ran benchmarks and codesize on ARM and AArch64, but showed minor improvements in performance and some codesize improvements.

However, this does seem to alter some of the tests in hexagon, in ways that I'm not 100% sure for these tests are "better". I think swp-carried has too many undef's for it to calculate the costs correctly. swp-epilog-phi5.ll now has a "loop0" and a "loop1" which may mean it's not pipelined any more? And two-combinations-bug.ll isn't showing the same behaviour as the bug is trying to test, so I've turned this extra cost calculation off there. My understanding is that because we are only altering the SetupCost, the last in the list of compared variables, this shouldn't really be making the loops worse in most cases.


https://reviews.llvm.org/D58770

Files:
  lib/Transforms/Scalar/LoopStrengthReduce.cpp
  test/CodeGen/ARM/lsr-setupcost.ll
  test/CodeGen/Hexagon/swp-carried-1.ll
  test/CodeGen/Hexagon/swp-epilog-phi5.ll
  test/Transforms/LoopStrengthReduce/two-combinations-bug.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D58770.188685.patch
Type: text/x-patch
Size: 6631 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190228/446e80d2/attachment.bin>


More information about the llvm-commits mailing list