From 67bf9a6154d4b82c6c01aad01141bf08c1bbd0f6 Mon Sep 17 00:00:00 2001 From: Sjoerd Meijer Date: Fri, 10 Jan 2020 09:30:02 +0000 Subject: [SVEV] Recognise hardware-loop intrinsic loop.decrement.reg Teach SCEV about the @loop.decrement.reg intrinsic, which has exactly the same semantics as a sub expression. This allows us to query hardware-loops, which contain this @loop.decrement.reg intrinsic, so that we can calculate iteration counts, exit values, etc. of hardwareloops. This "int_loop_decrement_reg" intrinsic is defined as "IntrNoDuplicate". Thus, while hardware-loops and tripcounts now become analysable by SCEV, this prevents the usual loop transformations from applying transformations on hardware-loops, which is what we want at this point, for which I have added test cases for loopunrolling and IndVarSimplify and LFTR. Differential Revision: https://reviews.llvm.org/D71563 --- llvm/lib/Analysis/ScalarEvolution.cpp | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'llvm/lib/Analysis/ScalarEvolution.cpp') diff --git a/llvm/lib/Analysis/ScalarEvolution.cpp b/llvm/lib/Analysis/ScalarEvolution.cpp index e636854ad6d..7d5c71eafed 100644 --- a/llvm/lib/Analysis/ScalarEvolution.cpp +++ b/llvm/lib/Analysis/ScalarEvolution.cpp @@ -4507,6 +4507,17 @@ static Optional MatchBinaryOp(Value *V, DominatorTree &DT) { if (!Op) return None; + // Recognise intrinsic loop.decrement.reg, and as this has exactly the same + // semantics as a Sub, return a binary sub expression. + if (auto *II = dyn_cast(V)) { + switch (II->getIntrinsicID()) { + case Intrinsic::loop_decrement_reg: + return BinaryOp(Instruction::Sub, II->getOperand(0), II->getOperand(1)); + default: + return None; + } + } + // Implementation detail: all the cleverness here should happen without // creating new SCEV expressions -- our caller knowns tricks to avoid creating // SCEV expressions when possible, and we should not break that. -- cgit v1.2.3