[PATCH] D55373: [LSR] Generate formulae to enable more indexed accesses

Gil Rapaport via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sun Feb 3 14:29:27 PST 2019


gilr added inline comments.


================
Comment at: lib/Transforms/Scalar/LoopStrengthReduce.cpp:159
+static cl::opt<bool> CollapseUnrolledCode(
+  "lsr-collapse-unrolled", cl::Hidden, cl::init(false),
+  cl::desc("Narrow LSR search space by collapsing unrolled code"));
----------------
samparker wrote:
> gilr wrote:
> > False by default?
> This option has been introduced to force the collapsing, even if the complexity limit hasn't been reached. Which is why it's implemented differently to the other, similar, options.
Aaargh, sorry, read it backwards ...
Is it needed since unrolled code doesn't initially go into the same LSRUse? If so, can FavorBackedgeIndex be used to have initial construction put them in the same LSRUse?


================
Comment at: lib/Transforms/Scalar/LoopStrengthReduce.cpp:2904
 
+  if (FavorBackedgeIndex)
+    return cost <= 1;
----------------
Deserves a comment.


================
Comment at: lib/Transforms/Scalar/LoopStrengthReduce.cpp:3121
     assert(UseI != Inc.UserInst->op_end() && "cannot find IV operand");
+    if (FavorBackedgeIndex && UseI->getUser() == Chain.lastNonPHI())
+      continue;
----------------
I'm a bit confused here. IIUC a profitable complete chain prvides an efficient solution using post-increments. Why break the last increment out?


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

https://reviews.llvm.org/D55373





More information about the llvm-commits mailing list