[PATCH] D25794: [SCEV] Add a threshold to restrict number of mul operands to be inlined into SCEV
Li Huang via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 20 13:01:46 PDT 2016
lihuang marked 2 inline comments as done.
lihuang added inline comments.
================
Comment at: lib/Analysis/ScalarEvolution.cpp:2514
while (const SCEVMulExpr *Mul = dyn_cast<SCEVMulExpr>(Ops[Idx])) {
+ if (Mul->getNumOperands() > MaxMulOpsToInline)
+ break;
----------------
sanjoy wrote:
> 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?
I agree, limiting the size of Ops is the right way. My previous change was wrong, it's limiting the number of ops to be inlined in a single iteration.
================
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 ]
----------------
sanjoy wrote:
> 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?
Yes I removed the loop. I thought I'd need a loop to trigger SCEV analysis. Thanks!
https://reviews.llvm.org/D25794
More information about the llvm-commits
mailing list