[PATCH] D152278: [SCEV] Compute SCEV for ashr(add(shl(x, n), c), m) instr triplet

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 8 13:36:23 PDT 2023


efriedma added inline comments.


================
Comment at: llvm/lib/Analysis/ScalarEvolution.cpp:7893
+          // type, so create a new Constant with type same as TruncTy
+          int64_t AddOperand = AddOperandCI->getSExtValue();
+          const SCEV *AddConstant = getConstant(TruncTy, AddOperand >> AShrAmt);
----------------
Is there some reason to expect that "c" fits into an int64_t?


================
Comment at: llvm/lib/Analysis/ScalarEvolution.cpp:7894
+          int64_t AddOperand = AddOperandCI->getSExtValue();
+          const SCEV *AddConstant = getConstant(TruncTy, AddOperand >> AShrAmt);
+
----------------
I guess the reason AddOperandCI has to be a constant is that this shift needs to constant-fold?


================
Comment at: llvm/lib/Analysis/ScalarEvolution.cpp:7897
+          // As of now only handle cases where n = m, and n should be a value
+          // corresponding to a 8, 16, 32 integer.
+          if (LShift->getOperand(1) == BO->RHS &&
----------------
This could be extended to cases where n is greater than m?  You can skip that for the initial patch, of course.

I don't really see any reason to restrict the shift amounts like this; the transform is pretty restricted even without that.  What effect are you worried about?


================
Comment at: llvm/test/Analysis/ScalarEvolution/sext-add-inreg.ll:37
+for.cond.cleanup:                                 ; preds = %for.body
+  ret i32 undef
+
----------------
Try to avoid "undef" in testcases where it isn't relevant.  I don't think it really has much effect here, but still.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D152278



More information about the llvm-commits mailing list