[PATCH] D25794: [SCEV] Add a threshold to restrict number of mul operands to be inlined into SCEV

Sanjoy Das via llvm-commits llvm-commits at lists.llvm.org
Thu Oct 20 01:00:15 PDT 2016

sanjoy added inline comments.

Comment at: lib/Analysis/ScalarEvolution.cpp:2514
     while (const SCEVMulExpr *Mul = dyn_cast<SCEVMulExpr>(Ops[Idx])) {
+      if (Mul->getNumOperands() > MaxMulOpsToInline)
+        break;
I'd have phrased the limit as a cap on the size of `Ops` (either `Ops.size()` directly, or a cap on the number of new elements added to `Ops` in this loop).  Any specific reason why you chose this approach over that?

Comment at: test/Analysis/ScalarEvolution/max-mulops-inline.ll:24
+for.cond1.preheader:                              ; preds = %for.body3, %entry
+  %mul.lcssa5 = phi i32 [ %a.promoted4, %entry ], [ %mul.5, %for.body3 ]
Can this test case be simplified?  For instance, why do we need a loop at all?  Why not just have a sequence of multiplication instructions in a single basic block?


More information about the llvm-commits mailing list