[PATCH] D26781: [LSR] Canonicalize formula and put recursive Reg related with current loop in ScaledReg.

Quentin Colombet via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 17 17:56:23 PST 2016


qcolombet added inline comments.


================
Comment at: lib/Transforms/Scalar/LoopStrengthReduce.cpp:384
 /// \see Formula::BaseRegs.
-bool Formula::isCanonical() const {
-  if (ScaledReg)
-    return Scale != 1 || !BaseRegs.empty();
-  return BaseRegs.size() <= 1;
+bool Formula::isCanonical(const Loop &L) const {
+  if (!ScaledReg)
----------------
While updating the canonical representation, please make sure to update the comment on Formula::BaseRegs.


================
Comment at: lib/Transforms/Scalar/LoopStrengthReduce.cpp:389
+  if (Scale != 0 && Scale != 1)
+    return true;
+
----------------
Shouldn't this be just Scale != 1.
I don't expect we would generate 0 scaled register.
What am I missing?


================
Comment at: lib/Transforms/Scalar/LoopStrengthReduce.cpp:1090
       // Otherwise, do not consider this formula at all.
-      Lose();
+      ++NumRegs;
       return;
----------------
This change shouldn't be part of the canonicalize patch IMO.


================
Comment at: lib/Transforms/Scalar/LoopStrengthReduce.cpp:1273
-
   if (!Formulae.empty() && RigidFormula)
     return false;
----------------
Why are we dropping this assert?
That doesn't sound right.


================
Comment at: lib/Transforms/Scalar/LoopStrengthReduce.cpp:1448
-  // compile time sake.
-  assert((F.isCanonical() || F.Scale != 0));
   return isAMCompletelyFolded(TTI, MinOffset, MaxOffset, Kind, AccessTy,
----------------
Ditto.


================
Comment at: lib/Transforms/Scalar/LoopStrengthReduce.cpp:3094
+
+  F.canonicalize(*L);
   if (!LU.InsertFormula(F))
----------------
So far I wanted the canonicalization process to be thoughtful, meaning, no implicit canonicalization like in this change.
The rationale is that in a lot of cases, we will try to canonicalize formulae that are canonical by construction, i.e., we waste compile time.
This is a trade-off between simplicity of the code and compile time.

Was it too complex to keep it that way?
Indeed, I wouldn't have expected we have to add calls to F.canonicalize, except where you changed something.

What am I saying is that unless the code becomes messy very quickly (or every InsertFormula call gets preceded by a call to canonicalize), I would rather keep it the way it was before.

Note: Aside from compile time, the main reason why I don't like that change is because the API looks strange now. I.e., F is not const anymore.


Repository:
  rL LLVM

https://reviews.llvm.org/D26781





More information about the llvm-commits mailing list