2016-04-25 01:55:41 +08:00
|
|
|
//===- ScalarEvolutionExpander.cpp - Scalar Evolution Analysis ------------===//
|
2005-07-30 08:12:19 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-30 04:36:04 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2005-07-30 08:12:19 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file contains the implementation of the scalar evolution expander,
|
|
|
|
// which is used to generate the code corresponding to a given scalar evolution
|
|
|
|
// expression.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/Analysis/ScalarEvolutionExpander.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2014-01-07 19:48:04 +08:00
|
|
|
#include "llvm/ADT/SmallSet.h"
|
2014-06-21 19:47:18 +08:00
|
|
|
#include "llvm/Analysis/InstructionSimplify.h"
|
2006-12-07 09:30:32 +08:00
|
|
|
#include "llvm/Analysis/LoopInfo.h"
|
Switch the SCEV expander and LoopStrengthReduce to use
TargetTransformInfo rather than TargetLowering, removing one of the
primary instances of the layering violation of Transforms depending
directly on Target.
This is a really big deal because LSR used to be a "special" pass that
could only be tested fully using llc and by looking at the full output
of it. It also couldn't run with any other loop passes because it had to
be created by the backend. No longer is this true. LSR is now just
a normal pass and we should probably lift the creation of LSR out of
lib/CodeGen/Passes.cpp and into the PassManagerBuilder. =] I've not done
this, or updated all of the tests to use opt and a triple, because
I suspect someone more familiar with LSR would do a better job. This
change should be essentially without functional impact for normal
compilations, and only change behvaior of targetless compilations.
The conversion required changing all of the LSR code to refer to the TTI
interfaces, which fortunately are very similar to TargetLowering's
interfaces. However, it also allowed us to *always* expect to have some
implementation around. I've pushed that simplification through the pass,
and leveraged it to simplify code somewhat. It required some test
updates for one of two things: either we used to skip some checks
altogether but now we get the default "no" answer for them, or we used
to have no information about the target and now we do have some.
I've also started the process of removing AddrMode, as the TTI interface
doesn't use it any longer. In some cases this simplifies code, and in
others it adds some complexity, but I think it's not a bad tradeoff even
there. Subsequent patches will try to clean this up even further and use
other (more appropriate) abstractions.
Yet again, almost all of the formatting changes brought to you by
clang-format. =]
llvm-svn: 171735
2013-01-07 22:41:08 +08:00
|
|
|
#include "llvm/Analysis/TargetTransformInfo.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/DataLayout.h"
|
2014-01-13 17:26:24 +08:00
|
|
|
#include "llvm/IR/Dominators.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
|
|
|
#include "llvm/IR/LLVMContext.h"
|
2015-04-14 11:20:28 +08:00
|
|
|
#include "llvm/IR/Module.h"
|
2015-06-25 03:28:40 +08:00
|
|
|
#include "llvm/IR/PatternMatch.h"
|
2011-10-08 07:46:21 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
2015-03-24 03:32:43 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2011-07-16 08:59:39 +08:00
|
|
|
|
2005-07-30 08:12:19 +08:00
|
|
|
using namespace llvm;
|
2015-06-25 03:28:40 +08:00
|
|
|
using namespace PatternMatch;
|
2005-07-30 08:12:19 +08:00
|
|
|
|
2010-07-10 00:42:04 +08:00
|
|
|
/// ReuseOrCreateCast - Arrange for there to be a cast of V to Ty at IP,
|
2010-06-19 21:25:23 +08:00
|
|
|
/// reusing an existing cast if a suitable one exists, moving an existing
|
|
|
|
/// cast if a suitable one exists but isn't in the right place, or
|
2010-07-10 00:42:04 +08:00
|
|
|
/// creating a new one.
|
2011-07-18 12:54:35 +08:00
|
|
|
Value *SCEVExpander::ReuseOrCreateCast(Value *V, Type *Ty,
|
2010-06-19 21:25:23 +08:00
|
|
|
Instruction::CastOps Op,
|
|
|
|
BasicBlock::iterator IP) {
|
2012-02-22 11:21:39 +08:00
|
|
|
// This function must be called with the builder having a valid insertion
|
|
|
|
// point. It doesn't need to be the actual IP where the uses of the returned
|
|
|
|
// cast will be added, but it must dominate such IP.
|
2012-02-27 10:13:03 +08:00
|
|
|
// We use this precondition to produce a cast that will dominate all its
|
|
|
|
// uses. In particular, this is crucial for the case where the builder's
|
|
|
|
// insertion point *is* the point where we were asked to put the cast.
|
2012-07-23 16:51:15 +08:00
|
|
|
// Since we don't know the builder's insertion point is actually
|
2012-02-22 11:21:39 +08:00
|
|
|
// where the uses will be added (only that it dominates it), we are
|
|
|
|
// not allowed to move it.
|
|
|
|
BasicBlock::iterator BIP = Builder.GetInsertPoint();
|
|
|
|
|
2014-04-15 12:59:12 +08:00
|
|
|
Instruction *Ret = nullptr;
|
2012-02-19 01:22:58 +08:00
|
|
|
|
2010-06-19 21:25:23 +08:00
|
|
|
// Check to see if there is already a cast!
|
2014-03-09 11:16:01 +08:00
|
|
|
for (User *U : V->users())
|
2010-07-10 00:39:02 +08:00
|
|
|
if (U->getType() == Ty)
|
2010-07-10 00:42:04 +08:00
|
|
|
if (CastInst *CI = dyn_cast<CastInst>(U))
|
2010-06-19 21:25:23 +08:00
|
|
|
if (CI->getOpcode() == Op) {
|
2012-02-22 11:44:46 +08:00
|
|
|
// If the cast isn't where we want it, create a new cast at IP.
|
|
|
|
// Likewise, do not reuse a cast at BIP because it must dominate
|
|
|
|
// instructions that might be inserted before BIP.
|
2012-02-22 11:21:39 +08:00
|
|
|
if (BasicBlock::iterator(CI) != IP || BIP == IP) {
|
2010-06-19 21:25:23 +08:00
|
|
|
// Create a new cast, and leave the old cast in place in case
|
|
|
|
// it is being used as an insert point. Clear its operand
|
|
|
|
// so that it doesn't hold anything live.
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
Ret = CastInst::Create(Op, V, Ty, "", &*IP);
|
2012-02-27 10:13:03 +08:00
|
|
|
Ret->takeName(CI);
|
|
|
|
CI->replaceAllUsesWith(Ret);
|
2010-06-19 21:25:23 +08:00
|
|
|
CI->setOperand(0, UndefValue::get(V->getType()));
|
2012-02-27 10:13:03 +08:00
|
|
|
break;
|
2010-06-19 21:25:23 +08:00
|
|
|
}
|
2012-02-27 10:13:03 +08:00
|
|
|
Ret = CI;
|
|
|
|
break;
|
2010-06-19 21:25:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Create a new cast.
|
2012-02-27 10:13:03 +08:00
|
|
|
if (!Ret)
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
Ret = CastInst::Create(Op, V, Ty, V->getName(), &*IP);
|
2012-02-27 10:13:03 +08:00
|
|
|
|
|
|
|
// We assert at the end of the function since IP might point to an
|
|
|
|
// instruction with different dominance properties than a cast
|
|
|
|
// (an invoke for example) and not dominate BIP (but the cast does).
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
assert(SE.DT.dominates(Ret, &*BIP));
|
2012-02-27 10:13:03 +08:00
|
|
|
|
|
|
|
rememberInstruction(Ret);
|
|
|
|
return Ret;
|
2010-06-19 21:25:23 +08:00
|
|
|
}
|
|
|
|
|
2015-10-27 15:36:42 +08:00
|
|
|
static BasicBlock::iterator findInsertPointAfter(Instruction *I,
|
|
|
|
BasicBlock *MustDominate) {
|
|
|
|
BasicBlock::iterator IP = ++I->getIterator();
|
|
|
|
if (auto *II = dyn_cast<InvokeInst>(I))
|
|
|
|
IP = II->getNormalDest()->begin();
|
|
|
|
|
|
|
|
while (isa<PHINode>(IP))
|
|
|
|
++IP;
|
|
|
|
|
2016-02-04 05:30:31 +08:00
|
|
|
if (isa<FuncletPadInst>(IP) || isa<LandingPadInst>(IP)) {
|
|
|
|
++IP;
|
|
|
|
} else if (isa<CatchSwitchInst>(IP)) {
|
|
|
|
IP = MustDominate->getFirstInsertionPt();
|
|
|
|
} else {
|
|
|
|
assert(!IP->isEHPad() && "unexpected eh pad!");
|
2015-10-27 15:36:42 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return IP;
|
|
|
|
}
|
|
|
|
|
2009-06-28 05:18:18 +08:00
|
|
|
/// InsertNoopCastOfTo - Insert a cast of V to the specified type,
|
|
|
|
/// which must be possible with a noop cast, doing what we can to share
|
|
|
|
/// the casts.
|
2011-07-18 12:54:35 +08:00
|
|
|
Value *SCEVExpander::InsertNoopCastOfTo(Value *V, Type *Ty) {
|
2009-06-28 05:18:18 +08:00
|
|
|
Instruction::CastOps Op = CastInst::getCastOpcode(V, false, Ty, false);
|
|
|
|
assert((Op == Instruction::BitCast ||
|
|
|
|
Op == Instruction::PtrToInt ||
|
|
|
|
Op == Instruction::IntToPtr) &&
|
|
|
|
"InsertNoopCastOfTo cannot perform non-noop casts!");
|
|
|
|
assert(SE.getTypeSizeInBits(V->getType()) == SE.getTypeSizeInBits(Ty) &&
|
|
|
|
"InsertNoopCastOfTo cannot change sizes!");
|
|
|
|
|
2009-04-16 11:18:22 +08:00
|
|
|
// Short-circuit unnecessary bitcasts.
|
2011-12-15 06:07:19 +08:00
|
|
|
if (Op == Instruction::BitCast) {
|
|
|
|
if (V->getType() == Ty)
|
|
|
|
return V;
|
|
|
|
if (CastInst *CI = dyn_cast<CastInst>(V)) {
|
|
|
|
if (CI->getOperand(0)->getType() == Ty)
|
|
|
|
return CI->getOperand(0);
|
|
|
|
}
|
|
|
|
}
|
2009-04-16 23:52:57 +08:00
|
|
|
// Short-circuit unnecessary inttoptr<->ptrtoint casts.
|
2009-06-28 05:18:18 +08:00
|
|
|
if ((Op == Instruction::PtrToInt || Op == Instruction::IntToPtr) &&
|
2009-05-02 01:00:00 +08:00
|
|
|
SE.getTypeSizeInBits(Ty) == SE.getTypeSizeInBits(V->getType())) {
|
2009-04-21 09:07:12 +08:00
|
|
|
if (CastInst *CI = dyn_cast<CastInst>(V))
|
|
|
|
if ((CI->getOpcode() == Instruction::PtrToInt ||
|
|
|
|
CI->getOpcode() == Instruction::IntToPtr) &&
|
|
|
|
SE.getTypeSizeInBits(CI->getType()) ==
|
|
|
|
SE.getTypeSizeInBits(CI->getOperand(0)->getType()))
|
|
|
|
return CI->getOperand(0);
|
2009-05-02 01:00:00 +08:00
|
|
|
if (ConstantExpr *CE = dyn_cast<ConstantExpr>(V))
|
|
|
|
if ((CE->getOpcode() == Instruction::PtrToInt ||
|
|
|
|
CE->getOpcode() == Instruction::IntToPtr) &&
|
|
|
|
SE.getTypeSizeInBits(CE->getType()) ==
|
|
|
|
SE.getTypeSizeInBits(CE->getOperand(0)->getType()))
|
|
|
|
return CE->getOperand(0);
|
|
|
|
}
|
2009-04-16 23:52:57 +08:00
|
|
|
|
2010-06-19 21:25:23 +08:00
|
|
|
// Fold a cast of a constant.
|
2006-02-04 17:51:53 +08:00
|
|
|
if (Constant *C = dyn_cast<Constant>(V))
|
2009-07-30 02:55:55 +08:00
|
|
|
return ConstantExpr::getCast(Op, C, Ty);
|
2009-08-21 00:42:55 +08:00
|
|
|
|
2010-06-19 21:25:23 +08:00
|
|
|
// Cast the argument at the beginning of the entry block, after
|
|
|
|
// any bitcasts of other arguments.
|
2006-02-04 17:51:53 +08:00
|
|
|
if (Argument *A = dyn_cast<Argument>(V)) {
|
2010-06-19 21:25:23 +08:00
|
|
|
BasicBlock::iterator IP = A->getParent()->getEntryBlock().begin();
|
|
|
|
while ((isa<BitCastInst>(IP) &&
|
|
|
|
isa<Argument>(cast<BitCastInst>(IP)->getOperand(0)) &&
|
|
|
|
cast<BitCastInst>(IP)->getOperand(0) != A) ||
|
2015-10-27 15:36:42 +08:00
|
|
|
isa<DbgInfoIntrinsic>(IP))
|
2010-06-19 21:25:23 +08:00
|
|
|
++IP;
|
|
|
|
return ReuseOrCreateCast(A, Ty, Op, IP);
|
2006-02-04 17:51:53 +08:00
|
|
|
}
|
2008-02-10 02:30:13 +08:00
|
|
|
|
2010-06-19 21:25:23 +08:00
|
|
|
// Cast the instruction immediately after the instruction.
|
2006-02-04 17:51:53 +08:00
|
|
|
Instruction *I = cast<Instruction>(V);
|
2015-10-28 03:48:28 +08:00
|
|
|
BasicBlock::iterator IP = findInsertPointAfter(I, Builder.GetInsertBlock());
|
2010-06-19 21:25:23 +08:00
|
|
|
return ReuseOrCreateCast(I, Ty, Op, IP);
|
2006-02-04 17:51:53 +08:00
|
|
|
}
|
|
|
|
|
2007-04-13 13:04:18 +08:00
|
|
|
/// InsertBinop - Insert the specified binary operator, doing a small amount
|
|
|
|
/// of work to avoid inserting an obviously redundant operation.
|
2009-06-28 05:18:18 +08:00
|
|
|
Value *SCEVExpander::InsertBinop(Instruction::BinaryOps Opcode,
|
|
|
|
Value *LHS, Value *RHS) {
|
2007-06-16 03:21:55 +08:00
|
|
|
// Fold a binop with constant operands.
|
|
|
|
if (Constant *CLHS = dyn_cast<Constant>(LHS))
|
|
|
|
if (Constant *CRHS = dyn_cast<Constant>(RHS))
|
2009-07-30 02:55:55 +08:00
|
|
|
return ConstantExpr::get(Opcode, CLHS, CRHS);
|
2007-06-16 03:21:55 +08:00
|
|
|
|
2007-04-13 13:04:18 +08:00
|
|
|
// Do a quick scan to see if we have this binop nearby. If so, reuse it.
|
|
|
|
unsigned ScanLimit = 6;
|
2009-06-28 05:18:18 +08:00
|
|
|
BasicBlock::iterator BlockBegin = Builder.GetInsertBlock()->begin();
|
|
|
|
// Scanning starts from the last instruction before the insertion point.
|
|
|
|
BasicBlock::iterator IP = Builder.GetInsertPoint();
|
|
|
|
if (IP != BlockBegin) {
|
2008-06-16 03:07:39 +08:00
|
|
|
--IP;
|
|
|
|
for (; ScanLimit; --IP, --ScanLimit) {
|
2010-03-06 05:12:40 +08:00
|
|
|
// Don't count dbg.value against the ScanLimit, to avoid perturbing the
|
|
|
|
// generated code.
|
|
|
|
if (isa<DbgInfoIntrinsic>(IP))
|
|
|
|
ScanLimit++;
|
2009-05-19 10:15:55 +08:00
|
|
|
if (IP->getOpcode() == (unsigned)Opcode && IP->getOperand(0) == LHS &&
|
|
|
|
IP->getOperand(1) == RHS)
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
return &*IP;
|
2008-06-16 03:07:39 +08:00
|
|
|
if (IP == BlockBegin) break;
|
|
|
|
}
|
2007-04-13 13:04:18 +08:00
|
|
|
}
|
2009-06-28 05:18:18 +08:00
|
|
|
|
2010-03-03 13:29:13 +08:00
|
|
|
// Save the original insertion point so we can restore it when we're done.
|
2013-09-30 23:40:17 +08:00
|
|
|
DebugLoc Loc = Builder.GetInsertPoint()->getDebugLoc();
|
2016-06-02 04:03:09 +08:00
|
|
|
SCEVInsertPointGuard Guard(Builder, this);
|
2010-03-03 13:29:13 +08:00
|
|
|
|
2016-12-13 02:52:32 +08:00
|
|
|
// Move the insertion point out of as many loops as we can.
|
|
|
|
while (const Loop *L = SE.LI.getLoopFor(Builder.GetInsertBlock())) {
|
|
|
|
if (!L->isLoopInvariant(LHS) || !L->isLoopInvariant(RHS)) break;
|
|
|
|
BasicBlock *Preheader = L->getLoopPreheader();
|
|
|
|
if (!Preheader) break;
|
2016-11-11 01:55:41 +08:00
|
|
|
|
2016-12-13 02:52:32 +08:00
|
|
|
// Ok, move up a level.
|
|
|
|
Builder.SetInsertPoint(Preheader->getTerminator());
|
2010-03-03 13:29:13 +08:00
|
|
|
}
|
|
|
|
|
2008-06-16 03:07:39 +08:00
|
|
|
// If we haven't found this binop, insert it.
|
2011-09-28 04:39:19 +08:00
|
|
|
Instruction *BO = cast<Instruction>(Builder.CreateBinOp(Opcode, LHS, RHS));
|
2013-09-30 23:40:17 +08:00
|
|
|
BO->setDebugLoc(Loc);
|
2010-01-21 10:09:26 +08:00
|
|
|
rememberInstruction(BO);
|
2010-03-03 13:29:13 +08:00
|
|
|
|
2009-05-02 01:13:31 +08:00
|
|
|
return BO;
|
2007-04-13 13:04:18 +08:00
|
|
|
}
|
|
|
|
|
2009-05-27 10:00:53 +08:00
|
|
|
/// FactorOutConstant - Test if S is divisible by Factor, using signed
|
2009-05-25 02:06:31 +08:00
|
|
|
/// division. If so, update S with Factor divided out and return true.
|
2010-03-02 01:49:51 +08:00
|
|
|
/// S need not be evenly divisible if a reasonable remainder can be
|
2009-05-27 10:00:53 +08:00
|
|
|
/// computed.
|
2009-05-25 02:06:31 +08:00
|
|
|
/// TODO: When ScalarEvolution gets a SCEVSDivExpr, this can be made
|
|
|
|
/// unnecessary; in its place, just signed-divide Ops[i] by the scale and
|
|
|
|
/// check to see if the divide was folded.
|
2015-03-10 10:37:25 +08:00
|
|
|
static bool FactorOutConstant(const SCEV *&S, const SCEV *&Remainder,
|
|
|
|
const SCEV *Factor, ScalarEvolution &SE,
|
|
|
|
const DataLayout &DL) {
|
2009-05-25 02:06:31 +08:00
|
|
|
// Everything is divisible by one.
|
2009-08-19 00:46:41 +08:00
|
|
|
if (Factor->isOne())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// x/x == 1.
|
|
|
|
if (S == Factor) {
|
2010-05-04 06:09:21 +08:00
|
|
|
S = SE.getConstant(S->getType(), 1);
|
2009-05-25 02:06:31 +08:00
|
|
|
return true;
|
2009-08-19 00:46:41 +08:00
|
|
|
}
|
2009-05-25 02:06:31 +08:00
|
|
|
|
|
|
|
// For a Constant, check for a multiple of the given factor.
|
2009-05-27 10:00:53 +08:00
|
|
|
if (const SCEVConstant *C = dyn_cast<SCEVConstant>(S)) {
|
2009-08-19 00:46:41 +08:00
|
|
|
// 0/x == 0.
|
|
|
|
if (C->isZero())
|
2009-05-25 02:06:31 +08:00
|
|
|
return true;
|
2009-08-19 00:46:41 +08:00
|
|
|
// Check for divisibility.
|
|
|
|
if (const SCEVConstant *FC = dyn_cast<SCEVConstant>(Factor)) {
|
|
|
|
ConstantInt *CI =
|
2015-12-18 04:28:46 +08:00
|
|
|
ConstantInt::get(SE.getContext(), C->getAPInt().sdiv(FC->getAPInt()));
|
2009-08-19 00:46:41 +08:00
|
|
|
// If the quotient is zero and the remainder is non-zero, reject
|
|
|
|
// the value at this scale. It will be considered for subsequent
|
|
|
|
// smaller scales.
|
|
|
|
if (!CI->isZero()) {
|
|
|
|
const SCEV *Div = SE.getConstant(CI);
|
|
|
|
S = Div;
|
2015-12-18 04:28:46 +08:00
|
|
|
Remainder = SE.getAddExpr(
|
|
|
|
Remainder, SE.getConstant(C->getAPInt().srem(FC->getAPInt())));
|
2009-08-19 00:46:41 +08:00
|
|
|
return true;
|
|
|
|
}
|
2009-05-25 02:06:31 +08:00
|
|
|
}
|
2009-05-27 10:00:53 +08:00
|
|
|
}
|
2009-05-25 02:06:31 +08:00
|
|
|
|
|
|
|
// In a Mul, check if there is a constant operand which is a multiple
|
|
|
|
// of the given factor.
|
2009-08-19 00:46:41 +08:00
|
|
|
if (const SCEVMulExpr *M = dyn_cast<SCEVMulExpr>(S)) {
|
2015-03-10 10:37:25 +08:00
|
|
|
// Size is known, check if there is a constant operand which is a multiple
|
|
|
|
// of the given factor. If so, we can factor it.
|
|
|
|
const SCEVConstant *FC = cast<SCEVConstant>(Factor);
|
|
|
|
if (const SCEVConstant *C = dyn_cast<SCEVConstant>(M->getOperand(0)))
|
2015-12-18 04:28:46 +08:00
|
|
|
if (!C->getAPInt().srem(FC->getAPInt())) {
|
2015-03-10 10:37:25 +08:00
|
|
|
SmallVector<const SCEV *, 4> NewMulOps(M->op_begin(), M->op_end());
|
2015-12-18 04:28:46 +08:00
|
|
|
NewMulOps[0] = SE.getConstant(C->getAPInt().sdiv(FC->getAPInt()));
|
2015-03-10 10:37:25 +08:00
|
|
|
S = SE.getMulExpr(NewMulOps);
|
|
|
|
return true;
|
2009-05-25 02:06:31 +08:00
|
|
|
}
|
2009-08-19 00:46:41 +08:00
|
|
|
}
|
2009-05-25 02:06:31 +08:00
|
|
|
|
|
|
|
// In an AddRec, check if both start and step are divisible.
|
|
|
|
if (const SCEVAddRecExpr *A = dyn_cast<SCEVAddRecExpr>(S)) {
|
2009-07-08 01:06:11 +08:00
|
|
|
const SCEV *Step = A->getStepRecurrence(SE);
|
2010-05-04 06:09:21 +08:00
|
|
|
const SCEV *StepRem = SE.getConstant(Step->getType(), 0);
|
2014-02-18 23:33:12 +08:00
|
|
|
if (!FactorOutConstant(Step, StepRem, Factor, SE, DL))
|
2009-05-27 10:00:53 +08:00
|
|
|
return false;
|
|
|
|
if (!StepRem->isZero())
|
|
|
|
return false;
|
2009-07-08 01:06:11 +08:00
|
|
|
const SCEV *Start = A->getStart();
|
2014-02-18 23:33:12 +08:00
|
|
|
if (!FactorOutConstant(Start, Remainder, Factor, SE, DL))
|
2009-05-25 02:06:31 +08:00
|
|
|
return false;
|
2013-07-14 11:10:08 +08:00
|
|
|
S = SE.getAddRecExpr(Start, Step, A->getLoop(),
|
|
|
|
A->getNoWrapFlags(SCEV::FlagNW));
|
2009-05-25 02:06:31 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2009-08-19 00:46:41 +08:00
|
|
|
/// SimplifyAddOperands - Sort and simplify a list of add operands. NumAddRecs
|
|
|
|
/// is the number of SCEVAddRecExprs present, which are kept at the end of
|
|
|
|
/// the list.
|
|
|
|
///
|
|
|
|
static void SimplifyAddOperands(SmallVectorImpl<const SCEV *> &Ops,
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty,
|
2009-08-19 00:46:41 +08:00
|
|
|
ScalarEvolution &SE) {
|
|
|
|
unsigned NumAddRecs = 0;
|
|
|
|
for (unsigned i = Ops.size(); i > 0 && isa<SCEVAddRecExpr>(Ops[i-1]); --i)
|
|
|
|
++NumAddRecs;
|
|
|
|
// Group Ops into non-addrecs and addrecs.
|
|
|
|
SmallVector<const SCEV *, 8> NoAddRecs(Ops.begin(), Ops.end() - NumAddRecs);
|
|
|
|
SmallVector<const SCEV *, 8> AddRecs(Ops.end() - NumAddRecs, Ops.end());
|
|
|
|
// Let ScalarEvolution sort and simplify the non-addrecs list.
|
|
|
|
const SCEV *Sum = NoAddRecs.empty() ?
|
2010-05-04 06:09:21 +08:00
|
|
|
SE.getConstant(Ty, 0) :
|
2009-08-19 00:46:41 +08:00
|
|
|
SE.getAddExpr(NoAddRecs);
|
|
|
|
// If it returned an add, use the operands. Otherwise it simplified
|
|
|
|
// the sum into a single value, so just use that.
|
2010-03-18 09:17:13 +08:00
|
|
|
Ops.clear();
|
2009-08-19 00:46:41 +08:00
|
|
|
if (const SCEVAddExpr *Add = dyn_cast<SCEVAddExpr>(Sum))
|
2010-06-22 03:47:52 +08:00
|
|
|
Ops.append(Add->op_begin(), Add->op_end());
|
2010-03-18 09:17:13 +08:00
|
|
|
else if (!Sum->isZero())
|
|
|
|
Ops.push_back(Sum);
|
2009-08-19 00:46:41 +08:00
|
|
|
// Then append the addrecs.
|
2010-06-22 03:47:52 +08:00
|
|
|
Ops.append(AddRecs.begin(), AddRecs.end());
|
2009-08-19 00:46:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// SplitAddRecs - Flatten a list of add operands, moving addrec start values
|
|
|
|
/// out to the top level. For example, convert {a + b,+,c} to a, b, {0,+,d}.
|
|
|
|
/// This helps expose more opportunities for folding parts of the expressions
|
|
|
|
/// into GEP indices.
|
|
|
|
///
|
|
|
|
static void SplitAddRecs(SmallVectorImpl<const SCEV *> &Ops,
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty,
|
2009-08-19 00:46:41 +08:00
|
|
|
ScalarEvolution &SE) {
|
|
|
|
// Find the addrecs.
|
|
|
|
SmallVector<const SCEV *, 8> AddRecs;
|
|
|
|
for (unsigned i = 0, e = Ops.size(); i != e; ++i)
|
|
|
|
while (const SCEVAddRecExpr *A = dyn_cast<SCEVAddRecExpr>(Ops[i])) {
|
|
|
|
const SCEV *Start = A->getStart();
|
|
|
|
if (Start->isZero()) break;
|
2010-05-04 06:09:21 +08:00
|
|
|
const SCEV *Zero = SE.getConstant(Ty, 0);
|
2009-08-19 00:46:41 +08:00
|
|
|
AddRecs.push_back(SE.getAddRecExpr(Zero,
|
|
|
|
A->getStepRecurrence(SE),
|
2011-03-15 00:50:06 +08:00
|
|
|
A->getLoop(),
|
2013-07-14 11:10:08 +08:00
|
|
|
A->getNoWrapFlags(SCEV::FlagNW)));
|
2009-08-19 00:46:41 +08:00
|
|
|
if (const SCEVAddExpr *Add = dyn_cast<SCEVAddExpr>(Start)) {
|
|
|
|
Ops[i] = Zero;
|
2010-06-22 03:47:52 +08:00
|
|
|
Ops.append(Add->op_begin(), Add->op_end());
|
2009-08-19 00:46:41 +08:00
|
|
|
e += Add->getNumOperands();
|
|
|
|
} else {
|
|
|
|
Ops[i] = Start;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!AddRecs.empty()) {
|
|
|
|
// Add the addrecs onto the end of the list.
|
2010-06-22 03:47:52 +08:00
|
|
|
Ops.append(AddRecs.begin(), AddRecs.end());
|
2009-08-19 00:46:41 +08:00
|
|
|
// Resort the operand list, moving any constants to the front.
|
|
|
|
SimplifyAddOperands(Ops, Ty, SE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-08-21 00:42:55 +08:00
|
|
|
/// expandAddToGEP - Expand an addition expression with a pointer type into
|
|
|
|
/// a GEP instead of using ptrtoint+arithmetic+inttoptr. This helps
|
|
|
|
/// BasicAliasAnalysis and other passes analyze the result. See the rules
|
|
|
|
/// for getelementptr vs. inttoptr in
|
|
|
|
/// http://llvm.org/docs/LangRef.html#pointeraliasing
|
|
|
|
/// for details.
|
2009-07-21 01:44:17 +08:00
|
|
|
///
|
2010-01-20 06:26:02 +08:00
|
|
|
/// Design note: The correctness of using getelementptr here depends on
|
2009-08-21 00:42:55 +08:00
|
|
|
/// ScalarEvolution not recognizing inttoptr and ptrtoint operators, as
|
|
|
|
/// they may introduce pointer arithmetic which may not be safely converted
|
|
|
|
/// into getelementptr.
|
2009-05-25 02:06:31 +08:00
|
|
|
///
|
|
|
|
/// Design note: It might seem desirable for this function to be more
|
|
|
|
/// loop-aware. If some of the indices are loop-invariant while others
|
|
|
|
/// aren't, it might seem desirable to emit multiple GEPs, keeping the
|
|
|
|
/// loop-invariant portions of the overall computation outside the loop.
|
|
|
|
/// However, there are a few reasons this is not done here. Hoisting simple
|
|
|
|
/// arithmetic is a low-level optimization that often isn't very
|
|
|
|
/// important until late in the optimization process. In fact, passes
|
|
|
|
/// like InstructionCombining will combine GEPs, even if it means
|
|
|
|
/// pushing loop-invariant computation down into loops, so even if the
|
|
|
|
/// GEPs were split here, the work would quickly be undone. The
|
|
|
|
/// LoopStrengthReduction pass, which is usually run quite late (and
|
|
|
|
/// after the last InstructionCombining pass), takes care of hoisting
|
|
|
|
/// loop-invariant portions of expressions, after considering what
|
|
|
|
/// can be folded using target addressing modes.
|
|
|
|
///
|
2009-07-08 01:06:11 +08:00
|
|
|
Value *SCEVExpander::expandAddToGEP(const SCEV *const *op_begin,
|
|
|
|
const SCEV *const *op_end,
|
2011-07-18 12:54:35 +08:00
|
|
|
PointerType *PTy,
|
|
|
|
Type *Ty,
|
2009-05-19 10:15:55 +08:00
|
|
|
Value *V) {
|
2015-03-25 07:34:31 +08:00
|
|
|
Type *OriginalElTy = PTy->getElementType();
|
|
|
|
Type *ElTy = OriginalElTy;
|
2009-05-19 10:15:55 +08:00
|
|
|
SmallVector<Value *, 4> GepIndices;
|
2009-07-08 01:06:11 +08:00
|
|
|
SmallVector<const SCEV *, 8> Ops(op_begin, op_end);
|
2009-05-19 10:15:55 +08:00
|
|
|
bool AnyNonZeroIndices = false;
|
|
|
|
|
2009-08-19 00:46:41 +08:00
|
|
|
// Split AddRecs up into parts as either of the parts may be usable
|
|
|
|
// without the other.
|
|
|
|
SplitAddRecs(Ops, Ty, SE);
|
|
|
|
|
2015-03-10 10:37:25 +08:00
|
|
|
Type *IntPtrTy = DL.getIntPtrType(PTy);
|
2013-09-11 03:55:24 +08:00
|
|
|
|
2009-12-04 09:33:04 +08:00
|
|
|
// Descend down the pointer's type and attempt to convert the other
|
2009-05-19 10:15:55 +08:00
|
|
|
// operands into GEP indices, at each level. The first index in a GEP
|
|
|
|
// indexes into the array implied by the pointer operand; the rest of
|
|
|
|
// the indices index into the element or field type selected by the
|
|
|
|
// preceding index.
|
|
|
|
for (;;) {
|
2009-08-19 00:46:41 +08:00
|
|
|
// If the scale size is not 0, attempt to factor out a scale for
|
|
|
|
// array indexing.
|
2009-07-08 01:06:11 +08:00
|
|
|
SmallVector<const SCEV *, 8> ScaledOps;
|
2010-01-28 14:32:46 +08:00
|
|
|
if (ElTy->isSized()) {
|
2013-09-11 03:55:24 +08:00
|
|
|
const SCEV *ElSize = SE.getSizeOfExpr(IntPtrTy, ElTy);
|
2010-01-28 14:32:46 +08:00
|
|
|
if (!ElSize->isZero()) {
|
|
|
|
SmallVector<const SCEV *, 8> NewOps;
|
2015-11-22 07:20:10 +08:00
|
|
|
for (const SCEV *Op : Ops) {
|
2010-05-04 06:09:21 +08:00
|
|
|
const SCEV *Remainder = SE.getConstant(Ty, 0);
|
2015-03-10 10:37:25 +08:00
|
|
|
if (FactorOutConstant(Op, Remainder, ElSize, SE, DL)) {
|
2010-01-28 14:32:46 +08:00
|
|
|
// Op now has ElSize factored out.
|
|
|
|
ScaledOps.push_back(Op);
|
|
|
|
if (!Remainder->isZero())
|
|
|
|
NewOps.push_back(Remainder);
|
|
|
|
AnyNonZeroIndices = true;
|
|
|
|
} else {
|
|
|
|
// The operand was not divisible, so add it to the list of operands
|
|
|
|
// we'll scan next iteration.
|
2015-11-22 07:20:10 +08:00
|
|
|
NewOps.push_back(Op);
|
2010-01-28 14:32:46 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
// If we made any changes, update Ops.
|
|
|
|
if (!ScaledOps.empty()) {
|
|
|
|
Ops = NewOps;
|
|
|
|
SimplifyAddOperands(Ops, Ty, SE);
|
2009-05-19 10:15:55 +08:00
|
|
|
}
|
2009-08-19 00:46:41 +08:00
|
|
|
}
|
2009-05-19 10:15:55 +08:00
|
|
|
}
|
2009-08-19 00:46:41 +08:00
|
|
|
|
|
|
|
// Record the scaled array index for this level of the type. If
|
|
|
|
// we didn't find any operands that could be factored, tentatively
|
|
|
|
// assume that element zero was selected (since the zero offset
|
|
|
|
// would obviously be folded away).
|
2009-05-19 10:15:55 +08:00
|
|
|
Value *Scaled = ScaledOps.empty() ?
|
2009-08-01 04:28:14 +08:00
|
|
|
Constant::getNullValue(Ty) :
|
2009-05-19 10:15:55 +08:00
|
|
|
expandCodeFor(SE.getAddExpr(ScaledOps), Ty);
|
|
|
|
GepIndices.push_back(Scaled);
|
|
|
|
|
|
|
|
// Collect struct field index operands.
|
2011-07-18 12:54:35 +08:00
|
|
|
while (StructType *STy = dyn_cast<StructType>(ElTy)) {
|
2009-08-19 00:46:41 +08:00
|
|
|
bool FoundFieldNo = false;
|
|
|
|
// An empty struct has no fields.
|
|
|
|
if (STy->getNumElements() == 0) break;
|
2015-03-10 10:37:25 +08:00
|
|
|
// Field offsets are known. See if a constant offset falls within any of
|
|
|
|
// the struct fields.
|
|
|
|
if (Ops.empty())
|
|
|
|
break;
|
|
|
|
if (const SCEVConstant *C = dyn_cast<SCEVConstant>(Ops[0]))
|
|
|
|
if (SE.getTypeSizeInBits(C->getType()) <= 64) {
|
|
|
|
const StructLayout &SL = *DL.getStructLayout(STy);
|
|
|
|
uint64_t FullOffset = C->getValue()->getZExtValue();
|
|
|
|
if (FullOffset < SL.getSizeInBytes()) {
|
|
|
|
unsigned ElIdx = SL.getElementContainingOffset(FullOffset);
|
|
|
|
GepIndices.push_back(
|
|
|
|
ConstantInt::get(Type::getInt32Ty(Ty->getContext()), ElIdx));
|
|
|
|
ElTy = STy->getTypeAtIndex(ElIdx);
|
|
|
|
Ops[0] =
|
2009-06-16 06:12:54 +08:00
|
|
|
SE.getConstant(Ty, FullOffset - SL.getElementOffset(ElIdx));
|
2015-03-10 10:37:25 +08:00
|
|
|
AnyNonZeroIndices = true;
|
|
|
|
FoundFieldNo = true;
|
2010-01-28 10:15:55 +08:00
|
|
|
}
|
2015-03-10 10:37:25 +08:00
|
|
|
}
|
2009-08-19 00:46:41 +08:00
|
|
|
// If no struct field offsets were found, tentatively assume that
|
|
|
|
// field zero was selected (since the zero offset would obviously
|
|
|
|
// be folded away).
|
|
|
|
if (!FoundFieldNo) {
|
|
|
|
ElTy = STy->getTypeAtIndex(0u);
|
|
|
|
GepIndices.push_back(
|
|
|
|
Constant::getNullValue(Type::getInt32Ty(Ty->getContext())));
|
|
|
|
}
|
|
|
|
}
|
2009-05-19 10:15:55 +08:00
|
|
|
|
2011-07-18 12:54:35 +08:00
|
|
|
if (ArrayType *ATy = dyn_cast<ArrayType>(ElTy))
|
2009-05-19 10:15:55 +08:00
|
|
|
ElTy = ATy->getElementType();
|
2009-08-19 00:46:41 +08:00
|
|
|
else
|
|
|
|
break;
|
2009-05-19 10:15:55 +08:00
|
|
|
}
|
|
|
|
|
2010-03-02 01:49:51 +08:00
|
|
|
// If none of the operands were convertible to proper GEP indices, cast
|
2009-05-19 10:15:55 +08:00
|
|
|
// the base to i8* and do an ugly getelementptr with that. It's still
|
|
|
|
// better than ptrtoint+arithmetic+inttoptr at least.
|
|
|
|
if (!AnyNonZeroIndices) {
|
2009-08-19 00:46:41 +08:00
|
|
|
// Cast the base to i8*.
|
2009-05-19 10:15:55 +08:00
|
|
|
V = InsertNoopCastOfTo(V,
|
2009-10-06 23:40:36 +08:00
|
|
|
Type::getInt8PtrTy(Ty->getContext(), PTy->getAddressSpace()));
|
2009-08-19 00:46:41 +08:00
|
|
|
|
2012-02-21 11:51:14 +08:00
|
|
|
assert(!isa<Instruction>(V) ||
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
SE.DT.dominates(cast<Instruction>(V), &*Builder.GetInsertPoint()));
|
2012-02-21 09:19:51 +08:00
|
|
|
|
2009-08-19 00:46:41 +08:00
|
|
|
// Expand the operands for a plain byte offset.
|
2009-06-10 01:18:38 +08:00
|
|
|
Value *Idx = expandCodeFor(SE.getAddExpr(Ops), Ty);
|
2009-05-19 10:15:55 +08:00
|
|
|
|
|
|
|
// Fold a GEP with constant operands.
|
|
|
|
if (Constant *CLHS = dyn_cast<Constant>(V))
|
|
|
|
if (Constant *CRHS = dyn_cast<Constant>(Idx))
|
2015-04-03 02:55:32 +08:00
|
|
|
return ConstantExpr::getGetElementPtr(Type::getInt8Ty(Ty->getContext()),
|
|
|
|
CLHS, CRHS);
|
2009-05-19 10:15:55 +08:00
|
|
|
|
|
|
|
// Do a quick scan to see if we have this GEP nearby. If so, reuse it.
|
|
|
|
unsigned ScanLimit = 6;
|
2009-06-28 05:18:18 +08:00
|
|
|
BasicBlock::iterator BlockBegin = Builder.GetInsertBlock()->begin();
|
|
|
|
// Scanning starts from the last instruction before the insertion point.
|
|
|
|
BasicBlock::iterator IP = Builder.GetInsertPoint();
|
|
|
|
if (IP != BlockBegin) {
|
2009-05-19 10:15:55 +08:00
|
|
|
--IP;
|
|
|
|
for (; ScanLimit; --IP, --ScanLimit) {
|
2010-03-06 05:12:40 +08:00
|
|
|
// Don't count dbg.value against the ScanLimit, to avoid perturbing the
|
|
|
|
// generated code.
|
|
|
|
if (isa<DbgInfoIntrinsic>(IP))
|
|
|
|
ScanLimit++;
|
2009-05-19 10:15:55 +08:00
|
|
|
if (IP->getOpcode() == Instruction::GetElementPtr &&
|
|
|
|
IP->getOperand(0) == V && IP->getOperand(1) == Idx)
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
return &*IP;
|
2009-05-19 10:15:55 +08:00
|
|
|
if (IP == BlockBegin) break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-03-03 13:29:13 +08:00
|
|
|
// Save the original insertion point so we can restore it when we're done.
|
2016-06-02 04:03:09 +08:00
|
|
|
SCEVInsertPointGuard Guard(Builder, this);
|
2010-03-03 13:29:13 +08:00
|
|
|
|
|
|
|
// Move the insertion point out of as many loops as we can.
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
while (const Loop *L = SE.LI.getLoopFor(Builder.GetInsertBlock())) {
|
2010-03-03 13:29:13 +08:00
|
|
|
if (!L->isLoopInvariant(V) || !L->isLoopInvariant(Idx)) break;
|
|
|
|
BasicBlock *Preheader = L->getLoopPreheader();
|
|
|
|
if (!Preheader) break;
|
|
|
|
|
|
|
|
// Ok, move up a level.
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
Builder.SetInsertPoint(Preheader->getTerminator());
|
2010-03-03 13:29:13 +08:00
|
|
|
}
|
|
|
|
|
2009-08-19 00:46:41 +08:00
|
|
|
// Emit a GEP.
|
2015-04-04 03:41:44 +08:00
|
|
|
Value *GEP = Builder.CreateGEP(Builder.getInt8Ty(), V, Idx, "uglygep");
|
2010-01-21 10:09:26 +08:00
|
|
|
rememberInstruction(GEP);
|
2010-03-03 13:29:13 +08:00
|
|
|
|
2009-05-19 10:15:55 +08:00
|
|
|
return GEP;
|
|
|
|
}
|
|
|
|
|
2016-06-02 04:03:09 +08:00
|
|
|
{
|
|
|
|
SCEVInsertPointGuard Guard(Builder, this);
|
2010-03-03 13:29:13 +08:00
|
|
|
|
2016-06-02 04:03:09 +08:00
|
|
|
// Move the insertion point out of as many loops as we can.
|
|
|
|
while (const Loop *L = SE.LI.getLoopFor(Builder.GetInsertBlock())) {
|
|
|
|
if (!L->isLoopInvariant(V)) break;
|
2010-03-03 13:29:13 +08:00
|
|
|
|
2016-08-12 05:15:00 +08:00
|
|
|
bool AnyIndexNotLoopInvariant = any_of(
|
|
|
|
GepIndices, [L](Value *Op) { return !L->isLoopInvariant(Op); });
|
2015-11-22 07:20:10 +08:00
|
|
|
|
2016-06-02 04:03:09 +08:00
|
|
|
if (AnyIndexNotLoopInvariant)
|
|
|
|
break;
|
2010-03-03 13:29:13 +08:00
|
|
|
|
2016-06-02 04:03:09 +08:00
|
|
|
BasicBlock *Preheader = L->getLoopPreheader();
|
|
|
|
if (!Preheader) break;
|
2010-03-03 13:29:13 +08:00
|
|
|
|
2016-06-02 04:03:09 +08:00
|
|
|
// Ok, move up a level.
|
|
|
|
Builder.SetInsertPoint(Preheader->getTerminator());
|
|
|
|
}
|
2010-03-03 13:29:13 +08:00
|
|
|
|
2016-06-02 04:03:09 +08:00
|
|
|
// Insert a pretty getelementptr. Note that this GEP is not marked inbounds,
|
|
|
|
// because ScalarEvolution may have changed the address arithmetic to
|
|
|
|
// compute a value which is beyond the end of the allocated object.
|
|
|
|
Value *Casted = V;
|
|
|
|
if (V->getType() != PTy)
|
|
|
|
Casted = InsertNoopCastOfTo(Casted, PTy);
|
|
|
|
Value *GEP = Builder.CreateGEP(OriginalElTy, Casted, GepIndices, "scevgep");
|
|
|
|
Ops.push_back(SE.getUnknown(GEP));
|
|
|
|
rememberInstruction(GEP);
|
|
|
|
}
|
2013-10-01 20:17:11 +08:00
|
|
|
|
2009-05-19 10:15:55 +08:00
|
|
|
return expand(SE.getAddExpr(Ops));
|
|
|
|
}
|
|
|
|
|
2010-03-03 13:29:13 +08:00
|
|
|
/// PickMostRelevantLoop - Given two loops pick the one that's most relevant for
|
|
|
|
/// SCEV expansion. If they are nested, this is the most nested. If they are
|
|
|
|
/// neighboring, pick the later.
|
|
|
|
static const Loop *PickMostRelevantLoop(const Loop *A, const Loop *B,
|
|
|
|
DominatorTree &DT) {
|
|
|
|
if (!A) return B;
|
|
|
|
if (!B) return A;
|
|
|
|
if (A->contains(B)) return B;
|
|
|
|
if (B->contains(A)) return A;
|
|
|
|
if (DT.dominates(A->getHeader(), B->getHeader())) return B;
|
|
|
|
if (DT.dominates(B->getHeader(), A->getHeader())) return A;
|
|
|
|
return A; // Arbitrarily break the tie.
|
|
|
|
}
|
|
|
|
|
2010-11-18 08:34:22 +08:00
|
|
|
/// getRelevantLoop - Get the most relevant loop associated with the given
|
2010-03-03 13:29:13 +08:00
|
|
|
/// expression, according to PickMostRelevantLoop.
|
2010-11-18 08:34:22 +08:00
|
|
|
const Loop *SCEVExpander::getRelevantLoop(const SCEV *S) {
|
|
|
|
// Test whether we've already computed the most relevant loop for this SCEV.
|
2015-11-22 07:20:10 +08:00
|
|
|
auto Pair = RelevantLoops.insert(std::make_pair(S, nullptr));
|
2010-11-18 08:34:22 +08:00
|
|
|
if (!Pair.second)
|
|
|
|
return Pair.first->second;
|
|
|
|
|
2010-03-03 13:29:13 +08:00
|
|
|
if (isa<SCEVConstant>(S))
|
2010-11-18 08:34:22 +08:00
|
|
|
// A constant has no relevant loops.
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2010-03-03 13:29:13 +08:00
|
|
|
if (const SCEVUnknown *U = dyn_cast<SCEVUnknown>(S)) {
|
|
|
|
if (const Instruction *I = dyn_cast<Instruction>(U->getValue()))
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
return Pair.first->second = SE.LI.getLoopFor(I->getParent());
|
2010-11-18 08:34:22 +08:00
|
|
|
// A non-instruction has no relevant loops.
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2010-03-03 13:29:13 +08:00
|
|
|
}
|
|
|
|
if (const SCEVNAryExpr *N = dyn_cast<SCEVNAryExpr>(S)) {
|
2014-04-15 12:59:12 +08:00
|
|
|
const Loop *L = nullptr;
|
2010-03-03 13:29:13 +08:00
|
|
|
if (const SCEVAddRecExpr *AR = dyn_cast<SCEVAddRecExpr>(S))
|
|
|
|
L = AR->getLoop();
|
2015-11-22 07:20:10 +08:00
|
|
|
for (const SCEV *Op : N->operands())
|
|
|
|
L = PickMostRelevantLoop(L, getRelevantLoop(Op), SE.DT);
|
2010-11-18 08:34:22 +08:00
|
|
|
return RelevantLoops[N] = L;
|
|
|
|
}
|
|
|
|
if (const SCEVCastExpr *C = dyn_cast<SCEVCastExpr>(S)) {
|
|
|
|
const Loop *Result = getRelevantLoop(C->getOperand());
|
|
|
|
return RelevantLoops[C] = Result;
|
|
|
|
}
|
|
|
|
if (const SCEVUDivExpr *D = dyn_cast<SCEVUDivExpr>(S)) {
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
const Loop *Result = PickMostRelevantLoop(
|
|
|
|
getRelevantLoop(D->getLHS()), getRelevantLoop(D->getRHS()), SE.DT);
|
2010-11-18 08:34:22 +08:00
|
|
|
return RelevantLoops[D] = Result;
|
2010-03-03 13:29:13 +08:00
|
|
|
}
|
|
|
|
llvm_unreachable("Unexpected SCEV type!");
|
|
|
|
}
|
2010-03-03 03:32:21 +08:00
|
|
|
|
2010-04-16 01:08:50 +08:00
|
|
|
namespace {
|
|
|
|
|
2010-03-03 13:29:13 +08:00
|
|
|
/// LoopCompare - Compare loops by PickMostRelevantLoop.
|
|
|
|
class LoopCompare {
|
|
|
|
DominatorTree &DT;
|
|
|
|
public:
|
|
|
|
explicit LoopCompare(DominatorTree &dt) : DT(dt) {}
|
|
|
|
|
|
|
|
bool operator()(std::pair<const Loop *, const SCEV *> LHS,
|
|
|
|
std::pair<const Loop *, const SCEV *> RHS) const {
|
2010-07-16 07:38:13 +08:00
|
|
|
// Keep pointer operands sorted at the end.
|
|
|
|
if (LHS.second->getType()->isPointerTy() !=
|
|
|
|
RHS.second->getType()->isPointerTy())
|
|
|
|
return LHS.second->getType()->isPointerTy();
|
|
|
|
|
2010-03-03 13:29:13 +08:00
|
|
|
// Compare loops with PickMostRelevantLoop.
|
|
|
|
if (LHS.first != RHS.first)
|
|
|
|
return PickMostRelevantLoop(LHS.first, RHS.first, DT) != LHS.first;
|
|
|
|
|
|
|
|
// If one operand is a non-constant negative and the other is not,
|
|
|
|
// put the non-constant negative on the right so that a sub can
|
|
|
|
// be used instead of a negate and add.
|
2012-01-07 08:27:31 +08:00
|
|
|
if (LHS.second->isNonConstantNegative()) {
|
|
|
|
if (!RHS.second->isNonConstantNegative())
|
2010-03-03 13:29:13 +08:00
|
|
|
return false;
|
2012-01-07 08:27:31 +08:00
|
|
|
} else if (RHS.second->isNonConstantNegative())
|
2010-03-03 13:29:13 +08:00
|
|
|
return true;
|
|
|
|
|
|
|
|
// Otherwise they are equivalent according to this comparison.
|
|
|
|
return false;
|
2009-08-19 00:46:41 +08:00
|
|
|
}
|
2010-03-03 13:29:13 +08:00
|
|
|
};
|
2009-05-19 10:15:55 +08:00
|
|
|
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2010-04-16 01:08:50 +08:00
|
|
|
|
2010-03-03 13:29:13 +08:00
|
|
|
Value *SCEVExpander::visitAddExpr(const SCEVAddExpr *S) {
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty = SE.getEffectiveSCEVType(S->getType());
|
2008-06-19 00:37:11 +08:00
|
|
|
|
2010-03-03 13:29:13 +08:00
|
|
|
// Collect all the add operands in a loop, along with their associated loops.
|
|
|
|
// Iterate in reverse so that constants are emitted last, all else equal, and
|
|
|
|
// so that pointer operands are inserted first, which the code below relies on
|
|
|
|
// to form more involved GEPs.
|
|
|
|
SmallVector<std::pair<const Loop *, const SCEV *>, 8> OpsAndLoops;
|
|
|
|
for (std::reverse_iterator<SCEVAddExpr::op_iterator> I(S->op_end()),
|
|
|
|
E(S->op_begin()); I != E; ++I)
|
2010-11-18 08:34:22 +08:00
|
|
|
OpsAndLoops.push_back(std::make_pair(getRelevantLoop(*I), *I));
|
2010-03-03 13:29:13 +08:00
|
|
|
|
|
|
|
// Sort by loop. Use a stable sort so that constants follow non-constants and
|
|
|
|
// pointer operands precede non-pointer operands.
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
std::stable_sort(OpsAndLoops.begin(), OpsAndLoops.end(), LoopCompare(SE.DT));
|
2010-03-03 13:29:13 +08:00
|
|
|
|
|
|
|
// Emit instructions to add all the operands. Hoist as much as possible
|
|
|
|
// out of loops, and form meaningful getelementptrs where possible.
|
2014-04-15 12:59:12 +08:00
|
|
|
Value *Sum = nullptr;
|
2015-11-22 07:20:10 +08:00
|
|
|
for (auto I = OpsAndLoops.begin(), E = OpsAndLoops.end(); I != E;) {
|
2010-03-03 13:29:13 +08:00
|
|
|
const Loop *CurLoop = I->first;
|
|
|
|
const SCEV *Op = I->second;
|
|
|
|
if (!Sum) {
|
|
|
|
// This is the first operand. Just expand it.
|
|
|
|
Sum = expand(Op);
|
|
|
|
++I;
|
2011-07-18 12:54:35 +08:00
|
|
|
} else if (PointerType *PTy = dyn_cast<PointerType>(Sum->getType())) {
|
2010-03-03 13:29:13 +08:00
|
|
|
// The running sum expression is a pointer. Try to form a getelementptr
|
|
|
|
// at this level with that as the base.
|
|
|
|
SmallVector<const SCEV *, 4> NewOps;
|
2010-07-16 07:38:13 +08:00
|
|
|
for (; I != E && I->first == CurLoop; ++I) {
|
|
|
|
// If the operand is SCEVUnknown and not instructions, peek through
|
|
|
|
// it, to enable more of it to be folded into the GEP.
|
|
|
|
const SCEV *X = I->second;
|
|
|
|
if (const SCEVUnknown *U = dyn_cast<SCEVUnknown>(X))
|
|
|
|
if (!isa<Instruction>(U->getValue()))
|
|
|
|
X = SE.getSCEV(U->getValue());
|
|
|
|
NewOps.push_back(X);
|
|
|
|
}
|
2010-03-03 13:29:13 +08:00
|
|
|
Sum = expandAddToGEP(NewOps.begin(), NewOps.end(), PTy, Ty, Sum);
|
2011-07-18 12:54:35 +08:00
|
|
|
} else if (PointerType *PTy = dyn_cast<PointerType>(Op->getType())) {
|
2010-03-03 13:29:13 +08:00
|
|
|
// The running sum is an integer, and there's a pointer at this level.
|
2010-04-10 03:14:31 +08:00
|
|
|
// Try to form a getelementptr. If the running sum is instructions,
|
|
|
|
// use a SCEVUnknown to avoid re-analyzing them.
|
2010-03-03 13:29:13 +08:00
|
|
|
SmallVector<const SCEV *, 4> NewOps;
|
2010-04-10 03:14:31 +08:00
|
|
|
NewOps.push_back(isa<Instruction>(Sum) ? SE.getUnknown(Sum) :
|
|
|
|
SE.getSCEV(Sum));
|
2010-03-03 13:29:13 +08:00
|
|
|
for (++I; I != E && I->first == CurLoop; ++I)
|
|
|
|
NewOps.push_back(I->second);
|
|
|
|
Sum = expandAddToGEP(NewOps.begin(), NewOps.end(), PTy, Ty, expand(Op));
|
2012-01-07 08:27:31 +08:00
|
|
|
} else if (Op->isNonConstantNegative()) {
|
2010-03-03 13:29:13 +08:00
|
|
|
// Instead of doing a negate and add, just do a subtract.
|
2010-01-21 10:09:26 +08:00
|
|
|
Value *W = expandCodeFor(SE.getNegativeSCEV(Op), Ty);
|
2010-03-03 13:29:13 +08:00
|
|
|
Sum = InsertNoopCastOfTo(Sum, Ty);
|
|
|
|
Sum = InsertBinop(Instruction::Sub, Sum, W);
|
|
|
|
++I;
|
2010-01-21 10:09:26 +08:00
|
|
|
} else {
|
2010-03-03 13:29:13 +08:00
|
|
|
// A simple add.
|
2010-01-21 10:09:26 +08:00
|
|
|
Value *W = expandCodeFor(Op, Ty);
|
2010-03-03 13:29:13 +08:00
|
|
|
Sum = InsertNoopCastOfTo(Sum, Ty);
|
|
|
|
// Canonicalize a constant to the RHS.
|
|
|
|
if (isa<Constant>(Sum)) std::swap(Sum, W);
|
|
|
|
Sum = InsertBinop(Instruction::Add, Sum, W);
|
|
|
|
++I;
|
2010-01-21 10:09:26 +08:00
|
|
|
}
|
2009-04-16 11:18:22 +08:00
|
|
|
}
|
2010-03-03 13:29:13 +08:00
|
|
|
|
|
|
|
return Sum;
|
2008-06-19 00:37:11 +08:00
|
|
|
}
|
2009-05-19 10:15:55 +08:00
|
|
|
|
2009-04-19 01:56:28 +08:00
|
|
|
Value *SCEVExpander::visitMulExpr(const SCEVMulExpr *S) {
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty = SE.getEffectiveSCEVType(S->getType());
|
2010-03-03 13:29:13 +08:00
|
|
|
|
|
|
|
// Collect all the mul operands in a loop, along with their associated loops.
|
|
|
|
// Iterate in reverse so that constants are emitted last, all else equal.
|
|
|
|
SmallVector<std::pair<const Loop *, const SCEV *>, 8> OpsAndLoops;
|
|
|
|
for (std::reverse_iterator<SCEVMulExpr::op_iterator> I(S->op_end()),
|
|
|
|
E(S->op_begin()); I != E; ++I)
|
2010-11-18 08:34:22 +08:00
|
|
|
OpsAndLoops.push_back(std::make_pair(getRelevantLoop(*I), *I));
|
2010-03-03 13:29:13 +08:00
|
|
|
|
|
|
|
// Sort by loop. Use a stable sort so that constants follow non-constants.
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
std::stable_sort(OpsAndLoops.begin(), OpsAndLoops.end(), LoopCompare(SE.DT));
|
2010-03-03 13:29:13 +08:00
|
|
|
|
|
|
|
// Emit instructions to mul all the operands. Hoist as much as possible
|
|
|
|
// out of loops.
|
2014-04-15 12:59:12 +08:00
|
|
|
Value *Prod = nullptr;
|
[SCEV] Teach SCEVExpander to expand BinPow
Current implementation of SCEVExpander demonstrates a very naive behavior when
it deals with power calculation. For example, a SCEV for x^8 looks like
(x * x * x * x * x * x * x * x)
If we try to expand it, it generates a very straightforward sequence of muls, like:
x2 = mul x, x
x3 = mul x2, x
x4 = mul x3, x
...
x8 = mul x7, x
This is a non-efficient way of doing that. A better way is to generate a sequence of
binary power calculation. In this case the expanded calculation will look like:
x2 = mul x, x
x4 = mul x2, x2
x8 = mul x4, x4
In some cases the code size reduction for such SCEVs is dramatic. If we had a loop:
x = a;
for (int i = 0; i < 3; i++)
x = x * x;
And this loop have been fully unrolled, we have something like:
x = a;
x2 = x * x;
x4 = x2 * x2;
x8 = x4 * x4;
The SCEV for x8 is the same as in example above, and if we for some reason
want to expand it, we will generate naively 7 multiplications instead of 3.
The BinPow expansion algorithm here allows to keep code size reasonable.
This patch teaches SCEV Expander to generate a sequence of BinPow multiplications
if we have repeating arguments in SCEVMulExpressions.
Differential Revision: https://reviews.llvm.org/D34025
llvm-svn: 305663
2017-06-19 14:24:53 +08:00
|
|
|
auto I = OpsAndLoops.begin();
|
|
|
|
|
|
|
|
// Expand the calculation of X pow N in the following manner:
|
|
|
|
// Let N = P1 + P2 + ... + PK, where all P are powers of 2. Then:
|
|
|
|
// X pow N = (X pow P1) * (X pow P2) * ... * (X pow PK).
|
|
|
|
const auto ExpandOpBinPowN = [this, &I, &OpsAndLoops, &Ty]() {
|
|
|
|
auto E = I;
|
|
|
|
// Calculate how many times the same operand from the same loop is included
|
|
|
|
// into this power.
|
|
|
|
uint64_t Exponent = 0;
|
|
|
|
const uint64_t MaxExponent = UINT64_MAX >> 1;
|
|
|
|
// No one sane will ever try to calculate such huge exponents, but if we
|
|
|
|
// need this, we stop on UINT64_MAX / 2 because we need to exit the loop
|
|
|
|
// below when the power of 2 exceeds our Exponent, and we want it to be
|
|
|
|
// 1u << 31 at most to not deal with unsigned overflow.
|
|
|
|
while (E != OpsAndLoops.end() && *I == *E && Exponent != MaxExponent) {
|
|
|
|
++Exponent;
|
|
|
|
++E;
|
|
|
|
}
|
|
|
|
assert(Exponent > 0 && "Trying to calculate a zeroth exponent of operand?");
|
|
|
|
|
|
|
|
// Calculate powers with exponents 1, 2, 4, 8 etc. and include those of them
|
|
|
|
// that are needed into the result.
|
|
|
|
Value *P = expandCodeFor(I->second, Ty);
|
|
|
|
Value *Result = nullptr;
|
|
|
|
if (Exponent & 1)
|
|
|
|
Result = P;
|
|
|
|
for (uint64_t BinExp = 2; BinExp <= Exponent; BinExp <<= 1) {
|
|
|
|
P = InsertBinop(Instruction::Mul, P, P);
|
|
|
|
if (Exponent & BinExp)
|
|
|
|
Result = Result ? InsertBinop(Instruction::Mul, Result, P) : P;
|
|
|
|
}
|
|
|
|
|
|
|
|
I = E;
|
|
|
|
assert(Result && "Nothing was expanded?");
|
|
|
|
return Result;
|
|
|
|
};
|
|
|
|
|
|
|
|
while (I != OpsAndLoops.end()) {
|
2010-03-03 13:29:13 +08:00
|
|
|
if (!Prod) {
|
|
|
|
// This is the first operand. Just expand it.
|
[SCEV] Teach SCEVExpander to expand BinPow
Current implementation of SCEVExpander demonstrates a very naive behavior when
it deals with power calculation. For example, a SCEV for x^8 looks like
(x * x * x * x * x * x * x * x)
If we try to expand it, it generates a very straightforward sequence of muls, like:
x2 = mul x, x
x3 = mul x2, x
x4 = mul x3, x
...
x8 = mul x7, x
This is a non-efficient way of doing that. A better way is to generate a sequence of
binary power calculation. In this case the expanded calculation will look like:
x2 = mul x, x
x4 = mul x2, x2
x8 = mul x4, x4
In some cases the code size reduction for such SCEVs is dramatic. If we had a loop:
x = a;
for (int i = 0; i < 3; i++)
x = x * x;
And this loop have been fully unrolled, we have something like:
x = a;
x2 = x * x;
x4 = x2 * x2;
x8 = x4 * x4;
The SCEV for x8 is the same as in example above, and if we for some reason
want to expand it, we will generate naively 7 multiplications instead of 3.
The BinPow expansion algorithm here allows to keep code size reasonable.
This patch teaches SCEV Expander to generate a sequence of BinPow multiplications
if we have repeating arguments in SCEVMulExpressions.
Differential Revision: https://reviews.llvm.org/D34025
llvm-svn: 305663
2017-06-19 14:24:53 +08:00
|
|
|
Prod = ExpandOpBinPowN();
|
|
|
|
} else if (I->second->isAllOnesValue()) {
|
2010-03-03 13:29:13 +08:00
|
|
|
// Instead of doing a multiply by negative one, just do a negate.
|
|
|
|
Prod = InsertNoopCastOfTo(Prod, Ty);
|
|
|
|
Prod = InsertBinop(Instruction::Sub, Constant::getNullValue(Ty), Prod);
|
[SCEV] Teach SCEVExpander to expand BinPow
Current implementation of SCEVExpander demonstrates a very naive behavior when
it deals with power calculation. For example, a SCEV for x^8 looks like
(x * x * x * x * x * x * x * x)
If we try to expand it, it generates a very straightforward sequence of muls, like:
x2 = mul x, x
x3 = mul x2, x
x4 = mul x3, x
...
x8 = mul x7, x
This is a non-efficient way of doing that. A better way is to generate a sequence of
binary power calculation. In this case the expanded calculation will look like:
x2 = mul x, x
x4 = mul x2, x2
x8 = mul x4, x4
In some cases the code size reduction for such SCEVs is dramatic. If we had a loop:
x = a;
for (int i = 0; i < 3; i++)
x = x * x;
And this loop have been fully unrolled, we have something like:
x = a;
x2 = x * x;
x4 = x2 * x2;
x8 = x4 * x4;
The SCEV for x8 is the same as in example above, and if we for some reason
want to expand it, we will generate naively 7 multiplications instead of 3.
The BinPow expansion algorithm here allows to keep code size reasonable.
This patch teaches SCEV Expander to generate a sequence of BinPow multiplications
if we have repeating arguments in SCEVMulExpressions.
Differential Revision: https://reviews.llvm.org/D34025
llvm-svn: 305663
2017-06-19 14:24:53 +08:00
|
|
|
++I;
|
2010-03-03 13:29:13 +08:00
|
|
|
} else {
|
|
|
|
// A simple mul.
|
[SCEV] Teach SCEVExpander to expand BinPow
Current implementation of SCEVExpander demonstrates a very naive behavior when
it deals with power calculation. For example, a SCEV for x^8 looks like
(x * x * x * x * x * x * x * x)
If we try to expand it, it generates a very straightforward sequence of muls, like:
x2 = mul x, x
x3 = mul x2, x
x4 = mul x3, x
...
x8 = mul x7, x
This is a non-efficient way of doing that. A better way is to generate a sequence of
binary power calculation. In this case the expanded calculation will look like:
x2 = mul x, x
x4 = mul x2, x2
x8 = mul x4, x4
In some cases the code size reduction for such SCEVs is dramatic. If we had a loop:
x = a;
for (int i = 0; i < 3; i++)
x = x * x;
And this loop have been fully unrolled, we have something like:
x = a;
x2 = x * x;
x4 = x2 * x2;
x8 = x4 * x4;
The SCEV for x8 is the same as in example above, and if we for some reason
want to expand it, we will generate naively 7 multiplications instead of 3.
The BinPow expansion algorithm here allows to keep code size reasonable.
This patch teaches SCEV Expander to generate a sequence of BinPow multiplications
if we have repeating arguments in SCEVMulExpressions.
Differential Revision: https://reviews.llvm.org/D34025
llvm-svn: 305663
2017-06-19 14:24:53 +08:00
|
|
|
Value *W = ExpandOpBinPowN();
|
2010-03-03 13:29:13 +08:00
|
|
|
Prod = InsertNoopCastOfTo(Prod, Ty);
|
|
|
|
// Canonicalize a constant to the RHS.
|
|
|
|
if (isa<Constant>(Prod)) std::swap(Prod, W);
|
2015-06-25 03:28:40 +08:00
|
|
|
const APInt *RHS;
|
|
|
|
if (match(W, m_Power2(RHS))) {
|
|
|
|
// Canonicalize Prod*(1<<C) to Prod<<C.
|
|
|
|
assert(!Ty->isVectorTy() && "vector types are not SCEVable");
|
|
|
|
Prod = InsertBinop(Instruction::Shl, Prod,
|
|
|
|
ConstantInt::get(Ty, RHS->logBase2()));
|
|
|
|
} else {
|
|
|
|
Prod = InsertBinop(Instruction::Mul, Prod, W);
|
|
|
|
}
|
2010-03-03 13:29:13 +08:00
|
|
|
}
|
2009-04-16 11:18:22 +08:00
|
|
|
}
|
|
|
|
|
2010-03-03 13:29:13 +08:00
|
|
|
return Prod;
|
2005-07-30 08:12:19 +08:00
|
|
|
}
|
|
|
|
|
2009-04-19 01:56:28 +08:00
|
|
|
Value *SCEVExpander::visitUDivExpr(const SCEVUDivExpr *S) {
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty = SE.getEffectiveSCEVType(S->getType());
|
2009-04-16 11:18:22 +08:00
|
|
|
|
2009-06-10 01:18:38 +08:00
|
|
|
Value *LHS = expandCodeFor(S->getLHS(), Ty);
|
2009-04-19 01:56:28 +08:00
|
|
|
if (const SCEVConstant *SC = dyn_cast<SCEVConstant>(S->getRHS())) {
|
2015-12-18 04:28:46 +08:00
|
|
|
const APInt &RHS = SC->getAPInt();
|
2008-07-08 13:05:37 +08:00
|
|
|
if (RHS.isPowerOf2())
|
|
|
|
return InsertBinop(Instruction::LShr, LHS,
|
2009-07-25 07:12:02 +08:00
|
|
|
ConstantInt::get(Ty, RHS.logBase2()));
|
2008-07-08 13:05:37 +08:00
|
|
|
}
|
|
|
|
|
2009-06-10 01:18:38 +08:00
|
|
|
Value *RHS = expandCodeFor(S->getRHS(), Ty);
|
2009-06-28 05:18:18 +08:00
|
|
|
return InsertBinop(Instruction::UDiv, LHS, RHS);
|
2008-07-08 13:05:37 +08:00
|
|
|
}
|
|
|
|
|
2009-05-25 02:06:31 +08:00
|
|
|
/// Move parts of Base into Rest to leave Base with the minimal
|
|
|
|
/// expression that provides a pointer operand suitable for a
|
|
|
|
/// GEP expansion.
|
2009-07-08 01:06:11 +08:00
|
|
|
static void ExposePointerBase(const SCEV *&Base, const SCEV *&Rest,
|
2009-05-25 02:06:31 +08:00
|
|
|
ScalarEvolution &SE) {
|
|
|
|
while (const SCEVAddRecExpr *A = dyn_cast<SCEVAddRecExpr>(Base)) {
|
|
|
|
Base = A->getStart();
|
|
|
|
Rest = SE.getAddExpr(Rest,
|
2010-05-04 06:09:21 +08:00
|
|
|
SE.getAddRecExpr(SE.getConstant(A->getType(), 0),
|
2009-05-25 02:06:31 +08:00
|
|
|
A->getStepRecurrence(SE),
|
2011-03-15 00:50:06 +08:00
|
|
|
A->getLoop(),
|
2013-07-14 11:10:08 +08:00
|
|
|
A->getNoWrapFlags(SCEV::FlagNW)));
|
2009-05-25 02:06:31 +08:00
|
|
|
}
|
|
|
|
if (const SCEVAddExpr *A = dyn_cast<SCEVAddExpr>(Base)) {
|
|
|
|
Base = A->getOperand(A->getNumOperands()-1);
|
2009-07-08 01:06:11 +08:00
|
|
|
SmallVector<const SCEV *, 8> NewAddOps(A->op_begin(), A->op_end());
|
2009-05-25 02:06:31 +08:00
|
|
|
NewAddOps.back() = Rest;
|
|
|
|
Rest = SE.getAddExpr(NewAddOps);
|
|
|
|
ExposePointerBase(Base, Rest, SE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-10-08 07:46:21 +08:00
|
|
|
/// Determine if this is a well-behaved chain of instructions leading back to
|
|
|
|
/// the PHI. If so, it may be reused by expanded expressions.
|
|
|
|
bool SCEVExpander::isNormalAddRecExprPHI(PHINode *PN, Instruction *IncV,
|
|
|
|
const Loop *L) {
|
|
|
|
if (IncV->getNumOperands() == 0 || isa<PHINode>(IncV) ||
|
|
|
|
(isa<CastInst>(IncV) && !isa<BitCastInst>(IncV)))
|
|
|
|
return false;
|
|
|
|
// If any of the operands don't dominate the insert position, bail.
|
|
|
|
// Addrec operands are always loop-invariant, so this can only happen
|
|
|
|
// if there are instructions which haven't been hoisted.
|
|
|
|
if (L == IVIncInsertLoop) {
|
|
|
|
for (User::op_iterator OI = IncV->op_begin()+1,
|
|
|
|
OE = IncV->op_end(); OI != OE; ++OI)
|
|
|
|
if (Instruction *OInst = dyn_cast<Instruction>(OI))
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
if (!SE.DT.dominates(OInst, IVIncInsertPos))
|
2011-10-08 07:46:21 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
// Advance to the next instruction.
|
|
|
|
IncV = dyn_cast<Instruction>(IncV->getOperand(0));
|
|
|
|
if (!IncV)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (IncV->mayHaveSideEffects())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (IncV != PN)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return isNormalAddRecExprPHI(PN, IncV, L);
|
|
|
|
}
|
|
|
|
|
2012-01-20 15:41:13 +08:00
|
|
|
/// getIVIncOperand returns an induction variable increment's induction
|
|
|
|
/// variable operand.
|
|
|
|
///
|
|
|
|
/// If allowScale is set, any type of GEP is allowed as long as the nonIV
|
|
|
|
/// operands dominate InsertPos.
|
|
|
|
///
|
|
|
|
/// If allowScale is not set, ensure that a GEP increment conforms to one of the
|
|
|
|
/// simple patterns generated by getAddRecExprPHILiterally and
|
|
|
|
/// expandAddtoGEP. If the pattern isn't recognized, return NULL.
|
|
|
|
Instruction *SCEVExpander::getIVIncOperand(Instruction *IncV,
|
|
|
|
Instruction *InsertPos,
|
|
|
|
bool allowScale) {
|
|
|
|
if (IncV == InsertPos)
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2012-01-10 09:45:08 +08:00
|
|
|
|
2011-10-08 07:46:21 +08:00
|
|
|
switch (IncV->getOpcode()) {
|
2012-01-20 15:41:13 +08:00
|
|
|
default:
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2011-10-08 07:46:21 +08:00
|
|
|
// Check for a simple Add/Sub or GEP of a loop invariant step.
|
|
|
|
case Instruction::Add:
|
2012-01-20 15:41:13 +08:00
|
|
|
case Instruction::Sub: {
|
|
|
|
Instruction *OInst = dyn_cast<Instruction>(IncV->getOperand(1));
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
if (!OInst || SE.DT.dominates(OInst, InsertPos))
|
2012-01-20 15:41:13 +08:00
|
|
|
return dyn_cast<Instruction>(IncV->getOperand(0));
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2012-01-20 15:41:13 +08:00
|
|
|
}
|
2011-10-08 07:46:21 +08:00
|
|
|
case Instruction::BitCast:
|
2012-01-20 15:41:13 +08:00
|
|
|
return dyn_cast<Instruction>(IncV->getOperand(0));
|
|
|
|
case Instruction::GetElementPtr:
|
2015-11-22 07:20:10 +08:00
|
|
|
for (auto I = IncV->op_begin() + 1, E = IncV->op_end(); I != E; ++I) {
|
2011-10-08 07:46:21 +08:00
|
|
|
if (isa<Constant>(*I))
|
|
|
|
continue;
|
2012-01-20 15:41:13 +08:00
|
|
|
if (Instruction *OInst = dyn_cast<Instruction>(*I)) {
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
if (!SE.DT.dominates(OInst, InsertPos))
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2012-01-20 15:41:13 +08:00
|
|
|
}
|
|
|
|
if (allowScale) {
|
|
|
|
// allow any kind of GEP as long as it can be hoisted.
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
// This must be a pointer addition of constants (pretty), which is already
|
|
|
|
// handled, or some number of address-size elements (ugly). Ugly geps
|
|
|
|
// have 2 operands. i1* is used by the expander to represent an
|
|
|
|
// address-size element.
|
2011-10-08 07:46:21 +08:00
|
|
|
if (IncV->getNumOperands() != 2)
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2011-10-15 14:19:55 +08:00
|
|
|
unsigned AS = cast<PointerType>(IncV->getType())->getAddressSpace();
|
2011-10-08 07:46:21 +08:00
|
|
|
if (IncV->getType() != Type::getInt1PtrTy(SE.getContext(), AS)
|
|
|
|
&& IncV->getType() != Type::getInt8PtrTy(SE.getContext(), AS))
|
2014-04-15 12:59:12 +08:00
|
|
|
return nullptr;
|
2011-10-08 07:46:21 +08:00
|
|
|
break;
|
|
|
|
}
|
2012-01-20 15:41:13 +08:00
|
|
|
return dyn_cast<Instruction>(IncV->getOperand(0));
|
2011-10-08 07:46:21 +08:00
|
|
|
}
|
2012-01-20 15:41:13 +08:00
|
|
|
}
|
|
|
|
|
2016-06-02 04:03:09 +08:00
|
|
|
/// If the insert point of the current builder or any of the builders on the
|
|
|
|
/// stack of saved builders has 'I' as its insert point, update it to point to
|
|
|
|
/// the instruction after 'I'. This is intended to be used when the instruction
|
|
|
|
/// 'I' is being moved. If this fixup is not done and 'I' is moved to a
|
|
|
|
/// different block, the inconsistent insert point (with a mismatched
|
|
|
|
/// Instruction and Block) can lead to an instruction being inserted in a block
|
|
|
|
/// other than its parent.
|
|
|
|
void SCEVExpander::fixupInsertPoints(Instruction *I) {
|
|
|
|
BasicBlock::iterator It(*I);
|
|
|
|
BasicBlock::iterator NewInsertPt = std::next(It);
|
|
|
|
if (Builder.GetInsertPoint() == It)
|
|
|
|
Builder.SetInsertPoint(&*NewInsertPt);
|
|
|
|
for (auto *InsertPtGuard : InsertPointGuards)
|
|
|
|
if (InsertPtGuard->GetInsertPoint() == It)
|
|
|
|
InsertPtGuard->SetInsertPoint(NewInsertPt);
|
|
|
|
}
|
|
|
|
|
2012-01-20 15:41:13 +08:00
|
|
|
/// hoistStep - Attempt to hoist a simple IV increment above InsertPos to make
|
|
|
|
/// it available to other uses in this loop. Recursively hoist any operands,
|
|
|
|
/// until we reach a value that dominates InsertPos.
|
|
|
|
bool SCEVExpander::hoistIVInc(Instruction *IncV, Instruction *InsertPos) {
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
if (SE.DT.dominates(IncV, InsertPos))
|
2012-01-20 15:41:13 +08:00
|
|
|
return true;
|
|
|
|
|
|
|
|
// InsertPos must itself dominate IncV so that IncV's new position satisfies
|
|
|
|
// its existing users.
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
if (isa<PHINode>(InsertPos) ||
|
|
|
|
!SE.DT.dominates(InsertPos->getParent(), IncV->getParent()))
|
2011-10-08 07:46:21 +08:00
|
|
|
return false;
|
2012-01-20 15:41:13 +08:00
|
|
|
|
2015-12-08 08:13:17 +08:00
|
|
|
if (!SE.LI.movementPreservesLCSSAForm(IncV, InsertPos))
|
|
|
|
return false;
|
|
|
|
|
2012-01-20 15:41:13 +08:00
|
|
|
// Check that the chain of IV operands leading back to Phi can be hoisted.
|
|
|
|
SmallVector<Instruction*, 4> IVIncs;
|
|
|
|
for(;;) {
|
|
|
|
Instruction *Oper = getIVIncOperand(IncV, InsertPos, /*allowScale*/true);
|
|
|
|
if (!Oper)
|
|
|
|
return false;
|
|
|
|
// IncV is safe to hoist.
|
|
|
|
IVIncs.push_back(IncV);
|
|
|
|
IncV = Oper;
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
if (SE.DT.dominates(IncV, InsertPos))
|
2012-01-20 15:41:13 +08:00
|
|
|
break;
|
|
|
|
}
|
2015-11-22 07:20:10 +08:00
|
|
|
for (auto I = IVIncs.rbegin(), E = IVIncs.rend(); I != E; ++I) {
|
2016-06-02 04:03:09 +08:00
|
|
|
fixupInsertPoints(*I);
|
2012-01-20 15:41:13 +08:00
|
|
|
(*I)->moveBefore(InsertPos);
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Determine if this cyclic phi is in a form that would have been generated by
|
|
|
|
/// LSR. We don't care if the phi was actually expanded in this pass, as long
|
|
|
|
/// as it is in a low-cost form, for example, no implied multiplication. This
|
|
|
|
/// should match any patterns generated by getAddRecExprPHILiterally and
|
|
|
|
/// expandAddtoGEP.
|
|
|
|
bool SCEVExpander::isExpandedAddRecExprPHI(PHINode *PN, Instruction *IncV,
|
|
|
|
const Loop *L) {
|
|
|
|
for(Instruction *IVOper = IncV;
|
|
|
|
(IVOper = getIVIncOperand(IVOper, L->getLoopPreheader()->getTerminator(),
|
|
|
|
/*allowScale=*/false));) {
|
|
|
|
if (IVOper == PN)
|
|
|
|
return true;
|
2011-10-08 07:46:21 +08:00
|
|
|
}
|
2012-01-20 15:41:13 +08:00
|
|
|
return false;
|
2011-10-08 07:46:21 +08:00
|
|
|
}
|
|
|
|
|
2011-11-30 14:07:54 +08:00
|
|
|
/// expandIVInc - Expand an IV increment at Builder's current InsertPos.
|
|
|
|
/// Typically this is the LatchBlock terminator or IVIncInsertPos, but we may
|
|
|
|
/// need to materialize IV increments elsewhere to handle difficult situations.
|
|
|
|
Value *SCEVExpander::expandIVInc(PHINode *PN, Value *StepV, const Loop *L,
|
|
|
|
Type *ExpandTy, Type *IntTy,
|
|
|
|
bool useSubtract) {
|
|
|
|
Value *IncV;
|
|
|
|
// If the PHI is a pointer, use a GEP, otherwise use an add or sub.
|
|
|
|
if (ExpandTy->isPointerTy()) {
|
|
|
|
PointerType *GEPPtrTy = cast<PointerType>(ExpandTy);
|
|
|
|
// If the step isn't constant, don't use an implicitly scaled GEP, because
|
|
|
|
// that would require a multiply inside the loop.
|
|
|
|
if (!isa<ConstantInt>(StepV))
|
|
|
|
GEPPtrTy = PointerType::get(Type::getInt1Ty(SE.getContext()),
|
|
|
|
GEPPtrTy->getAddressSpace());
|
|
|
|
const SCEV *const StepArray[1] = { SE.getSCEV(StepV) };
|
|
|
|
IncV = expandAddToGEP(StepArray, StepArray+1, GEPPtrTy, IntTy, PN);
|
|
|
|
if (IncV->getType() != PN->getType()) {
|
|
|
|
IncV = Builder.CreateBitCast(IncV, PN->getType());
|
|
|
|
rememberInstruction(IncV);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
IncV = useSubtract ?
|
|
|
|
Builder.CreateSub(PN, StepV, Twine(IVName) + ".iv.next") :
|
|
|
|
Builder.CreateAdd(PN, StepV, Twine(IVName) + ".iv.next");
|
|
|
|
rememberInstruction(IncV);
|
|
|
|
}
|
|
|
|
return IncV;
|
|
|
|
}
|
|
|
|
|
2014-02-16 23:49:50 +08:00
|
|
|
/// \brief Hoist the addrec instruction chain rooted in the loop phi above the
|
|
|
|
/// position. This routine assumes that this is possible (has been checked).
|
2016-06-02 04:03:09 +08:00
|
|
|
void SCEVExpander::hoistBeforePos(DominatorTree *DT, Instruction *InstToHoist,
|
|
|
|
Instruction *Pos, PHINode *LoopPhi) {
|
2014-02-16 23:49:50 +08:00
|
|
|
do {
|
|
|
|
if (DT->dominates(InstToHoist, Pos))
|
|
|
|
break;
|
|
|
|
// Make sure the increment is where we want it. But don't move it
|
|
|
|
// down past a potential existing post-inc user.
|
2016-06-02 04:03:09 +08:00
|
|
|
fixupInsertPoints(InstToHoist);
|
2014-02-16 23:49:50 +08:00
|
|
|
InstToHoist->moveBefore(Pos);
|
|
|
|
Pos = InstToHoist;
|
|
|
|
InstToHoist = cast<Instruction>(InstToHoist->getOperand(0));
|
|
|
|
} while (InstToHoist != LoopPhi);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Check whether we can cheaply express the requested SCEV in terms of
|
2015-08-09 02:27:36 +08:00
|
|
|
/// the available PHI SCEV by truncation and/or inversion of the step.
|
2014-02-16 23:49:50 +08:00
|
|
|
static bool canBeCheaplyTransformed(ScalarEvolution &SE,
|
|
|
|
const SCEVAddRecExpr *Phi,
|
|
|
|
const SCEVAddRecExpr *Requested,
|
|
|
|
bool &InvertStep) {
|
|
|
|
Type *PhiTy = SE.getEffectiveSCEVType(Phi->getType());
|
|
|
|
Type *RequestedTy = SE.getEffectiveSCEVType(Requested->getType());
|
|
|
|
|
|
|
|
if (RequestedTy->getIntegerBitWidth() > PhiTy->getIntegerBitWidth())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Try truncate it if necessary.
|
|
|
|
Phi = dyn_cast<SCEVAddRecExpr>(SE.getTruncateOrNoop(Phi, RequestedTy));
|
|
|
|
if (!Phi)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Check whether truncation will help.
|
|
|
|
if (Phi == Requested) {
|
|
|
|
InvertStep = false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check whether inverting will help: {R,+,-1} == R - {0,+,1}.
|
|
|
|
if (SE.getAddExpr(Requested->getStart(),
|
|
|
|
SE.getNegativeSCEV(Requested)) == Phi) {
|
|
|
|
InvertStep = true;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
Bugfix: SCEVExpander incorrectly marks increment operations as no-wrap
(The change was landed in r230280 and caused the regression PR22674.
This version contains a fix and a test-case for PR22674).
When emitting the increment operation, SCEVExpander marks the
operation as nuw or nsw based on the flags on the preincrement SCEV.
This is incorrect because, for instance, it is possible that {-6,+,1}
is <nuw> while {-6,+,1}+1 = {-5,+,1} is not.
This change teaches SCEV to mark the increment as nuw/nsw only if it
can explicitly prove that the increment operation won't overflow.
Apart from the attached test case, another (more realistic)
manifestation of the bug can be seen in
Transforms/IndVarSimplify/pr20680.ll.
Differential Revision: http://reviews.llvm.org/D7778
llvm-svn: 230533
2015-02-26 04:02:59 +08:00
|
|
|
static bool IsIncrementNSW(ScalarEvolution &SE, const SCEVAddRecExpr *AR) {
|
|
|
|
if (!isa<IntegerType>(AR->getType()))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
unsigned BitWidth = cast<IntegerType>(AR->getType())->getBitWidth();
|
|
|
|
Type *WideTy = IntegerType::get(AR->getType()->getContext(), BitWidth * 2);
|
|
|
|
const SCEV *Step = AR->getStepRecurrence(SE);
|
|
|
|
const SCEV *OpAfterExtend = SE.getAddExpr(SE.getSignExtendExpr(Step, WideTy),
|
|
|
|
SE.getSignExtendExpr(AR, WideTy));
|
|
|
|
const SCEV *ExtendAfterOp =
|
|
|
|
SE.getSignExtendExpr(SE.getAddExpr(AR, Step), WideTy);
|
|
|
|
return ExtendAfterOp == OpAfterExtend;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool IsIncrementNUW(ScalarEvolution &SE, const SCEVAddRecExpr *AR) {
|
|
|
|
if (!isa<IntegerType>(AR->getType()))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
unsigned BitWidth = cast<IntegerType>(AR->getType())->getBitWidth();
|
|
|
|
Type *WideTy = IntegerType::get(AR->getType()->getContext(), BitWidth * 2);
|
|
|
|
const SCEV *Step = AR->getStepRecurrence(SE);
|
|
|
|
const SCEV *OpAfterExtend = SE.getAddExpr(SE.getZeroExtendExpr(Step, WideTy),
|
|
|
|
SE.getZeroExtendExpr(AR, WideTy));
|
|
|
|
const SCEV *ExtendAfterOp =
|
|
|
|
SE.getZeroExtendExpr(SE.getAddExpr(AR, Step), WideTy);
|
|
|
|
return ExtendAfterOp == OpAfterExtend;
|
|
|
|
}
|
|
|
|
|
2010-01-21 10:09:26 +08:00
|
|
|
/// getAddRecExprPHILiterally - Helper for expandAddRecExprLiterally. Expand
|
|
|
|
/// the base addrec, which is the addrec without any non-loop-dominating
|
|
|
|
/// values, and return the PHI.
|
|
|
|
PHINode *
|
|
|
|
SCEVExpander::getAddRecExprPHILiterally(const SCEVAddRecExpr *Normalized,
|
|
|
|
const Loop *L,
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *ExpandTy,
|
2014-02-16 23:49:50 +08:00
|
|
|
Type *IntTy,
|
|
|
|
Type *&TruncTy,
|
|
|
|
bool &InvertStep) {
|
2011-07-17 06:26:27 +08:00
|
|
|
assert((!IVIncInsertLoop||IVIncInsertPos) && "Uninitialized insert position");
|
2011-07-16 08:59:39 +08:00
|
|
|
|
2010-01-21 10:09:26 +08:00
|
|
|
// Reuse a previously-inserted PHI, if present.
|
2011-10-08 07:46:21 +08:00
|
|
|
BasicBlock *LatchBlock = L->getLoopLatch();
|
|
|
|
if (LatchBlock) {
|
2014-04-15 12:59:12 +08:00
|
|
|
PHINode *AddRecPhiMatch = nullptr;
|
|
|
|
Instruction *IncV = nullptr;
|
|
|
|
TruncTy = nullptr;
|
2014-02-16 23:49:50 +08:00
|
|
|
InvertStep = false;
|
|
|
|
|
|
|
|
// Only try partially matching scevs that need truncation and/or
|
|
|
|
// step-inversion if we know this loop is outside the current loop.
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
bool TryNonMatchingSCEV =
|
|
|
|
IVIncInsertLoop &&
|
|
|
|
SE.DT.properlyDominates(LatchBlock, IVIncInsertLoop->getHeader());
|
2014-02-16 23:49:50 +08:00
|
|
|
|
2015-11-22 07:20:10 +08:00
|
|
|
for (auto &I : *L->getHeader()) {
|
|
|
|
auto *PN = dyn_cast<PHINode>(&I);
|
|
|
|
if (!PN || !SE.isSCEVable(PN->getType()))
|
2011-10-08 07:46:21 +08:00
|
|
|
continue;
|
|
|
|
|
2014-02-16 23:49:50 +08:00
|
|
|
const SCEVAddRecExpr *PhiSCEV = dyn_cast<SCEVAddRecExpr>(SE.getSCEV(PN));
|
|
|
|
if (!PhiSCEV)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
bool IsMatchingSCEV = PhiSCEV == Normalized;
|
|
|
|
// We only handle truncation and inversion of phi recurrences for the
|
|
|
|
// expanded expression if the expanded expression's loop dominates the
|
|
|
|
// loop we insert to. Check now, so we can bail out early.
|
|
|
|
if (!IsMatchingSCEV && !TryNonMatchingSCEV)
|
|
|
|
continue;
|
2011-10-08 07:46:21 +08:00
|
|
|
|
2014-02-16 23:49:50 +08:00
|
|
|
Instruction *TempIncV =
|
|
|
|
cast<Instruction>(PN->getIncomingValueForBlock(LatchBlock));
|
|
|
|
|
|
|
|
// Check whether we can reuse this PHI node.
|
2011-10-08 07:46:21 +08:00
|
|
|
if (LSRMode) {
|
2014-02-16 23:49:50 +08:00
|
|
|
if (!isExpandedAddRecExprPHI(PN, TempIncV, L))
|
2011-10-08 07:46:21 +08:00
|
|
|
continue;
|
2014-02-16 23:49:50 +08:00
|
|
|
if (L == IVIncInsertLoop && !hoistIVInc(TempIncV, IVIncInsertPos))
|
2011-10-08 07:46:21 +08:00
|
|
|
continue;
|
2014-02-16 23:49:50 +08:00
|
|
|
} else {
|
|
|
|
if (!isNormalAddRecExprPHI(PN, TempIncV, L))
|
2014-02-16 02:16:56 +08:00
|
|
|
continue;
|
2014-02-16 01:11:56 +08:00
|
|
|
}
|
2014-02-16 23:49:50 +08:00
|
|
|
|
|
|
|
// Stop if we have found an exact match SCEV.
|
|
|
|
if (IsMatchingSCEV) {
|
|
|
|
IncV = TempIncV;
|
2014-04-15 12:59:12 +08:00
|
|
|
TruncTy = nullptr;
|
2014-02-16 23:49:50 +08:00
|
|
|
InvertStep = false;
|
|
|
|
AddRecPhiMatch = PN;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Try whether the phi can be translated into the requested form
|
|
|
|
// (truncated and/or offset by a constant).
|
|
|
|
if ((!TruncTy || InvertStep) &&
|
|
|
|
canBeCheaplyTransformed(SE, PhiSCEV, Normalized, InvertStep)) {
|
|
|
|
// Record the phi node. But don't stop we might find an exact match
|
|
|
|
// later.
|
|
|
|
AddRecPhiMatch = PN;
|
|
|
|
IncV = TempIncV;
|
|
|
|
TruncTy = SE.getEffectiveSCEVType(Normalized->getType());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (AddRecPhiMatch) {
|
|
|
|
// Potentially, move the increment. We have made sure in
|
|
|
|
// isExpandedAddRecExprPHI or hoistIVInc that this is possible.
|
|
|
|
if (L == IVIncInsertLoop)
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
hoistBeforePos(&SE.DT, IncV, IVIncInsertPos, AddRecPhiMatch);
|
2014-02-16 23:49:50 +08:00
|
|
|
|
2011-10-08 07:46:21 +08:00
|
|
|
// Ok, the add recurrence looks usable.
|
|
|
|
// Remember this PHI, even in post-inc mode.
|
2014-02-16 23:49:50 +08:00
|
|
|
InsertedValues.insert(AddRecPhiMatch);
|
2011-10-08 07:46:21 +08:00
|
|
|
// Remember the increment.
|
|
|
|
rememberInstruction(IncV);
|
2014-02-16 23:49:50 +08:00
|
|
|
return AddRecPhiMatch;
|
2011-10-08 07:46:21 +08:00
|
|
|
}
|
|
|
|
}
|
2010-01-21 10:09:26 +08:00
|
|
|
|
|
|
|
// Save the original insertion point so we can restore it when we're done.
|
2016-06-02 04:03:09 +08:00
|
|
|
SCEVInsertPointGuard Guard(Builder, this);
|
2010-01-21 10:09:26 +08:00
|
|
|
|
2011-12-20 09:42:24 +08:00
|
|
|
// Another AddRec may need to be recursively expanded below. For example, if
|
|
|
|
// this AddRec is quadratic, the StepV may itself be an AddRec in this
|
|
|
|
// loop. Remove this loop from the PostIncLoops set before expanding such
|
|
|
|
// AddRecs. Otherwise, we cannot find a valid position for the step
|
|
|
|
// (i.e. StepV can never dominate its loop header). Ideally, we could do
|
|
|
|
// SavedIncLoops.swap(PostIncLoops), but we generally have a single element,
|
|
|
|
// so it's not worth implementing SmallPtrSet::swap.
|
|
|
|
PostIncLoopSet SavedPostIncLoops = PostIncLoops;
|
|
|
|
PostIncLoops.clear();
|
|
|
|
|
2016-12-12 03:02:21 +08:00
|
|
|
// Expand code for the start value into the loop preheader.
|
|
|
|
assert(L->getLoopPreheader() &&
|
|
|
|
"Can't expand add recurrences without a loop preheader!");
|
|
|
|
Value *StartV = expandCodeFor(Normalized->getStart(), ExpandTy,
|
|
|
|
L->getLoopPreheader()->getTerminator());
|
|
|
|
|
|
|
|
// StartV must have been be inserted into L's preheader to dominate the new
|
|
|
|
// phi.
|
2011-07-17 06:26:27 +08:00
|
|
|
assert(!isa<Instruction>(StartV) ||
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
SE.DT.properlyDominates(cast<Instruction>(StartV)->getParent(),
|
|
|
|
L->getHeader()));
|
2011-07-16 08:59:39 +08:00
|
|
|
|
2011-11-30 14:07:54 +08:00
|
|
|
// Expand code for the step value. Do this before creating the PHI so that PHI
|
|
|
|
// reuse code doesn't see an incomplete PHI.
|
2010-01-21 10:09:26 +08:00
|
|
|
const SCEV *Step = Normalized->getStepRecurrence(SE);
|
2011-11-30 14:07:54 +08:00
|
|
|
// If the stride is negative, insert a sub instead of an add for the increment
|
|
|
|
// (unless it's a constant, because subtracts of constants are canonicalized
|
|
|
|
// to adds).
|
2012-01-07 08:27:31 +08:00
|
|
|
bool useSubtract = !ExpandTy->isPointerTy() && Step->isNonConstantNegative();
|
2011-11-30 14:07:54 +08:00
|
|
|
if (useSubtract)
|
2010-01-21 10:09:26 +08:00
|
|
|
Step = SE.getNegativeSCEV(Step);
|
2011-11-30 14:07:54 +08:00
|
|
|
// Expand the step somewhere that dominates the loop header.
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
Value *StepV = expandCodeFor(Step, IntTy, &L->getHeader()->front());
|
2010-01-21 10:09:26 +08:00
|
|
|
|
2015-02-27 03:51:35 +08:00
|
|
|
// The no-wrap behavior proved by IsIncrement(NUW|NSW) is only applicable if
|
|
|
|
// we actually do emit an addition. It does not apply if we emit a
|
|
|
|
// subtraction.
|
|
|
|
bool IncrementIsNUW = !useSubtract && IsIncrementNUW(SE, Normalized);
|
|
|
|
bool IncrementIsNSW = !useSubtract && IsIncrementNSW(SE, Normalized);
|
|
|
|
|
2010-01-21 10:09:26 +08:00
|
|
|
// Create the PHI.
|
2011-03-30 19:19:20 +08:00
|
|
|
BasicBlock *Header = L->getHeader();
|
|
|
|
Builder.SetInsertPoint(Header, Header->begin());
|
|
|
|
pred_iterator HPB = pred_begin(Header), HPE = pred_end(Header);
|
2011-06-28 13:07:32 +08:00
|
|
|
PHINode *PN = Builder.CreatePHI(ExpandTy, std::distance(HPB, HPE),
|
2011-06-28 13:41:52 +08:00
|
|
|
Twine(IVName) + ".iv");
|
2010-01-21 10:09:26 +08:00
|
|
|
rememberInstruction(PN);
|
|
|
|
|
|
|
|
// Create the step instructions and populate the PHI.
|
2011-03-30 19:19:20 +08:00
|
|
|
for (pred_iterator HPI = HPB; HPI != HPE; ++HPI) {
|
2010-01-21 10:09:26 +08:00
|
|
|
BasicBlock *Pred = *HPI;
|
|
|
|
|
|
|
|
// Add a start value.
|
|
|
|
if (!L->contains(Pred)) {
|
|
|
|
PN->addIncoming(StartV, Pred);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2011-11-30 14:07:54 +08:00
|
|
|
// Create a step value and add it to the PHI.
|
|
|
|
// If IVIncInsertLoop is non-null and equal to the addrec's loop, insert the
|
|
|
|
// instructions at IVIncInsertPos.
|
2010-01-21 10:09:26 +08:00
|
|
|
Instruction *InsertPos = L == IVIncInsertLoop ?
|
|
|
|
IVIncInsertPos : Pred->getTerminator();
|
2011-07-06 05:48:22 +08:00
|
|
|
Builder.SetInsertPoint(InsertPos);
|
2011-11-30 14:07:54 +08:00
|
|
|
Value *IncV = expandIVInc(PN, StepV, L, ExpandTy, IntTy, useSubtract);
|
Bugfix: SCEVExpander incorrectly marks increment operations as no-wrap
(The change was landed in r230280 and caused the regression PR22674.
This version contains a fix and a test-case for PR22674).
When emitting the increment operation, SCEVExpander marks the
operation as nuw or nsw based on the flags on the preincrement SCEV.
This is incorrect because, for instance, it is possible that {-6,+,1}
is <nuw> while {-6,+,1}+1 = {-5,+,1} is not.
This change teaches SCEV to mark the increment as nuw/nsw only if it
can explicitly prove that the increment operation won't overflow.
Apart from the attached test case, another (more realistic)
manifestation of the bug can be seen in
Transforms/IndVarSimplify/pr20680.ll.
Differential Revision: http://reviews.llvm.org/D7778
llvm-svn: 230533
2015-02-26 04:02:59 +08:00
|
|
|
|
2013-07-14 10:50:07 +08:00
|
|
|
if (isa<OverflowingBinaryOperator>(IncV)) {
|
Bugfix: SCEVExpander incorrectly marks increment operations as no-wrap
(The change was landed in r230280 and caused the regression PR22674.
This version contains a fix and a test-case for PR22674).
When emitting the increment operation, SCEVExpander marks the
operation as nuw or nsw based on the flags on the preincrement SCEV.
This is incorrect because, for instance, it is possible that {-6,+,1}
is <nuw> while {-6,+,1}+1 = {-5,+,1} is not.
This change teaches SCEV to mark the increment as nuw/nsw only if it
can explicitly prove that the increment operation won't overflow.
Apart from the attached test case, another (more realistic)
manifestation of the bug can be seen in
Transforms/IndVarSimplify/pr20680.ll.
Differential Revision: http://reviews.llvm.org/D7778
llvm-svn: 230533
2015-02-26 04:02:59 +08:00
|
|
|
if (IncrementIsNUW)
|
2013-07-14 10:50:07 +08:00
|
|
|
cast<BinaryOperator>(IncV)->setHasNoUnsignedWrap();
|
Bugfix: SCEVExpander incorrectly marks increment operations as no-wrap
(The change was landed in r230280 and caused the regression PR22674.
This version contains a fix and a test-case for PR22674).
When emitting the increment operation, SCEVExpander marks the
operation as nuw or nsw based on the flags on the preincrement SCEV.
This is incorrect because, for instance, it is possible that {-6,+,1}
is <nuw> while {-6,+,1}+1 = {-5,+,1} is not.
This change teaches SCEV to mark the increment as nuw/nsw only if it
can explicitly prove that the increment operation won't overflow.
Apart from the attached test case, another (more realistic)
manifestation of the bug can be seen in
Transforms/IndVarSimplify/pr20680.ll.
Differential Revision: http://reviews.llvm.org/D7778
llvm-svn: 230533
2015-02-26 04:02:59 +08:00
|
|
|
if (IncrementIsNSW)
|
2013-07-14 10:50:07 +08:00
|
|
|
cast<BinaryOperator>(IncV)->setHasNoSignedWrap();
|
|
|
|
}
|
2010-01-21 10:09:26 +08:00
|
|
|
PN->addIncoming(IncV, Pred);
|
|
|
|
}
|
|
|
|
|
2011-12-20 09:42:24 +08:00
|
|
|
// After expanding subexpressions, restore the PostIncLoops set so the caller
|
|
|
|
// can ensure that IVIncrement dominates the current uses.
|
|
|
|
PostIncLoops = SavedPostIncLoops;
|
|
|
|
|
2010-01-21 10:09:26 +08:00
|
|
|
// Remember this PHI, even in post-inc mode.
|
|
|
|
InsertedValues.insert(PN);
|
|
|
|
|
|
|
|
return PN;
|
|
|
|
}
|
|
|
|
|
|
|
|
Value *SCEVExpander::expandAddRecExprLiterally(const SCEVAddRecExpr *S) {
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *STy = S->getType();
|
|
|
|
Type *IntTy = SE.getEffectiveSCEVType(STy);
|
2010-01-21 10:09:26 +08:00
|
|
|
const Loop *L = S->getLoop();
|
|
|
|
|
|
|
|
// Determine a normalized form of this expression, which is the expression
|
|
|
|
// before any post-inc adjustment is made.
|
|
|
|
const SCEVAddRecExpr *Normalized = S;
|
2010-04-08 06:27:08 +08:00
|
|
|
if (PostIncLoops.count(L)) {
|
|
|
|
PostIncLoopSet Loops;
|
|
|
|
Loops.insert(L);
|
2017-04-14 23:49:59 +08:00
|
|
|
Normalized = cast<SCEVAddRecExpr>(normalizeForPostIncUse(S, Loops, SE));
|
2010-01-21 10:09:26 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Strip off any non-loop-dominating component from the addrec start.
|
|
|
|
const SCEV *Start = Normalized->getStart();
|
2014-04-15 12:59:12 +08:00
|
|
|
const SCEV *PostLoopOffset = nullptr;
|
2010-11-18 05:41:58 +08:00
|
|
|
if (!SE.properlyDominates(Start, L->getHeader())) {
|
2010-01-21 10:09:26 +08:00
|
|
|
PostLoopOffset = Start;
|
2010-05-04 06:09:21 +08:00
|
|
|
Start = SE.getConstant(Normalized->getType(), 0);
|
2011-03-15 00:50:06 +08:00
|
|
|
Normalized = cast<SCEVAddRecExpr>(
|
|
|
|
SE.getAddRecExpr(Start, Normalized->getStepRecurrence(SE),
|
|
|
|
Normalized->getLoop(),
|
2013-07-14 11:10:08 +08:00
|
|
|
Normalized->getNoWrapFlags(SCEV::FlagNW)));
|
2010-01-21 10:09:26 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Strip off any non-loop-dominating component from the addrec step.
|
|
|
|
const SCEV *Step = Normalized->getStepRecurrence(SE);
|
2014-04-15 12:59:12 +08:00
|
|
|
const SCEV *PostLoopScale = nullptr;
|
2010-11-18 05:41:58 +08:00
|
|
|
if (!SE.dominates(Step, L->getHeader())) {
|
2010-01-21 10:09:26 +08:00
|
|
|
PostLoopScale = Step;
|
2010-05-04 06:09:21 +08:00
|
|
|
Step = SE.getConstant(Normalized->getType(), 1);
|
2016-07-13 09:28:12 +08:00
|
|
|
if (!Start->isZero()) {
|
|
|
|
// The normalization below assumes that Start is constant zero, so if
|
|
|
|
// it isn't re-associate Start to PostLoopOffset.
|
|
|
|
assert(!PostLoopOffset && "Start not-null but PostLoopOffset set?");
|
|
|
|
PostLoopOffset = Start;
|
|
|
|
Start = SE.getConstant(Normalized->getType(), 0);
|
|
|
|
}
|
2010-01-21 10:09:26 +08:00
|
|
|
Normalized =
|
2013-07-14 11:10:08 +08:00
|
|
|
cast<SCEVAddRecExpr>(SE.getAddRecExpr(
|
|
|
|
Start, Step, Normalized->getLoop(),
|
|
|
|
Normalized->getNoWrapFlags(SCEV::FlagNW)));
|
2010-01-21 10:09:26 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Expand the core addrec. If we need post-loop scaling, force it to
|
|
|
|
// expand to an integer type to avoid the need for additional casting.
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *ExpandTy = PostLoopScale ? IntTy : STy;
|
2017-05-27 11:22:55 +08:00
|
|
|
// We can't use a pointer type for the addrec if the pointer type is
|
|
|
|
// non-integral.
|
|
|
|
Type *AddRecPHIExpandTy =
|
|
|
|
DL.isNonIntegralPointerType(STy) ? Normalized->getType() : ExpandTy;
|
|
|
|
|
2014-02-16 23:49:50 +08:00
|
|
|
// In some cases, we decide to reuse an existing phi node but need to truncate
|
|
|
|
// it and/or invert the step.
|
2014-04-15 12:59:12 +08:00
|
|
|
Type *TruncTy = nullptr;
|
2014-02-16 23:49:50 +08:00
|
|
|
bool InvertStep = false;
|
2017-05-27 11:22:55 +08:00
|
|
|
PHINode *PN = getAddRecExprPHILiterally(Normalized, L, AddRecPHIExpandTy,
|
|
|
|
IntTy, TruncTy, InvertStep);
|
2010-01-21 10:09:26 +08:00
|
|
|
|
2010-03-02 01:49:51 +08:00
|
|
|
// Accommodate post-inc mode, if necessary.
|
2010-01-21 10:09:26 +08:00
|
|
|
Value *Result;
|
2010-04-08 06:27:08 +08:00
|
|
|
if (!PostIncLoops.count(L))
|
2010-01-21 10:09:26 +08:00
|
|
|
Result = PN;
|
|
|
|
else {
|
|
|
|
// In PostInc mode, use the post-incremented value.
|
|
|
|
BasicBlock *LatchBlock = L->getLoopLatch();
|
|
|
|
assert(LatchBlock && "PostInc mode requires a unique loop latch!");
|
|
|
|
Result = PN->getIncomingValueForBlock(LatchBlock);
|
2011-10-14 05:55:29 +08:00
|
|
|
|
|
|
|
// For an expansion to use the postinc form, the client must call
|
|
|
|
// expandCodeFor with an InsertPoint that is either outside the PostIncLoop
|
|
|
|
// or dominated by IVIncInsertPos.
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
if (isa<Instruction>(Result) &&
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
!SE.DT.dominates(cast<Instruction>(Result),
|
|
|
|
&*Builder.GetInsertPoint())) {
|
2011-11-30 14:07:54 +08:00
|
|
|
// The induction variable's postinc expansion does not dominate this use.
|
|
|
|
// IVUsers tries to prevent this case, so it is rare. However, it can
|
|
|
|
// happen when an IVUser outside the loop is not dominated by the latch
|
|
|
|
// block. Adjusting IVIncInsertPos before expansion begins cannot handle
|
|
|
|
// all cases. Consider a phi outide whose operand is replaced during
|
|
|
|
// expansion with the value of the postinc user. Without fundamentally
|
|
|
|
// changing the way postinc users are tracked, the only remedy is
|
|
|
|
// inserting an extra IV increment. StepV might fold into PostLoopOffset,
|
|
|
|
// but hopefully expandCodeFor handles that.
|
|
|
|
bool useSubtract =
|
2012-01-07 08:27:31 +08:00
|
|
|
!ExpandTy->isPointerTy() && Step->isNonConstantNegative();
|
2011-11-30 14:07:54 +08:00
|
|
|
if (useSubtract)
|
|
|
|
Step = SE.getNegativeSCEV(Step);
|
2013-09-30 23:40:17 +08:00
|
|
|
Value *StepV;
|
|
|
|
{
|
|
|
|
// Expand the step somewhere that dominates the loop header.
|
2016-06-02 04:03:09 +08:00
|
|
|
SCEVInsertPointGuard Guard(Builder, this);
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
StepV = expandCodeFor(Step, IntTy, &L->getHeader()->front());
|
2013-09-30 23:40:17 +08:00
|
|
|
}
|
2011-11-30 14:07:54 +08:00
|
|
|
Result = expandIVInc(PN, StepV, L, ExpandTy, IntTy, useSubtract);
|
|
|
|
}
|
2010-01-21 10:09:26 +08:00
|
|
|
}
|
|
|
|
|
2014-02-16 23:49:50 +08:00
|
|
|
// We have decided to reuse an induction variable of a dominating loop. Apply
|
|
|
|
// truncation and/or invertion of the step.
|
|
|
|
if (TruncTy) {
|
|
|
|
Type *ResTy = Result->getType();
|
|
|
|
// Normalize the result type.
|
|
|
|
if (ResTy != SE.getEffectiveSCEVType(ResTy))
|
|
|
|
Result = InsertNoopCastOfTo(Result, SE.getEffectiveSCEVType(ResTy));
|
|
|
|
// Truncate the result.
|
|
|
|
if (TruncTy != Result->getType()) {
|
|
|
|
Result = Builder.CreateTrunc(Result, TruncTy);
|
|
|
|
rememberInstruction(Result);
|
|
|
|
}
|
|
|
|
// Invert the result.
|
|
|
|
if (InvertStep) {
|
|
|
|
Result = Builder.CreateSub(expandCodeFor(Normalized->getStart(), TruncTy),
|
|
|
|
Result);
|
|
|
|
rememberInstruction(Result);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-01-21 10:09:26 +08:00
|
|
|
// Re-apply any non-loop-dominating scale.
|
|
|
|
if (PostLoopScale) {
|
2013-10-26 05:35:56 +08:00
|
|
|
assert(S->isAffine() && "Can't linearly scale non-affine recurrences.");
|
2010-02-13 04:39:25 +08:00
|
|
|
Result = InsertNoopCastOfTo(Result, IntTy);
|
2010-01-21 10:09:26 +08:00
|
|
|
Result = Builder.CreateMul(Result,
|
|
|
|
expandCodeFor(PostLoopScale, IntTy));
|
|
|
|
rememberInstruction(Result);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Re-apply any non-loop-dominating offset.
|
|
|
|
if (PostLoopOffset) {
|
2011-07-18 12:54:35 +08:00
|
|
|
if (PointerType *PTy = dyn_cast<PointerType>(ExpandTy)) {
|
2017-05-27 11:22:55 +08:00
|
|
|
if (Result->getType()->isIntegerTy()) {
|
|
|
|
Value *Base = expandCodeFor(PostLoopOffset, ExpandTy);
|
|
|
|
const SCEV *const OffsetArray[1] = {SE.getUnknown(Result)};
|
|
|
|
Result = expandAddToGEP(OffsetArray, OffsetArray + 1, PTy, IntTy, Base);
|
|
|
|
} else {
|
|
|
|
const SCEV *const OffsetArray[1] = {PostLoopOffset};
|
|
|
|
Result =
|
|
|
|
expandAddToGEP(OffsetArray, OffsetArray + 1, PTy, IntTy, Result);
|
|
|
|
}
|
2010-01-21 10:09:26 +08:00
|
|
|
} else {
|
2010-02-13 04:39:25 +08:00
|
|
|
Result = InsertNoopCastOfTo(Result, IntTy);
|
2010-01-21 10:09:26 +08:00
|
|
|
Result = Builder.CreateAdd(Result,
|
|
|
|
expandCodeFor(PostLoopOffset, IntTy));
|
|
|
|
rememberInstruction(Result);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
2009-04-19 01:56:28 +08:00
|
|
|
Value *SCEVExpander::visitAddRecExpr(const SCEVAddRecExpr *S) {
|
2010-01-21 10:09:26 +08:00
|
|
|
if (!CanonicalMode) return expandAddRecExprLiterally(S);
|
|
|
|
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty = SE.getEffectiveSCEVType(S->getType());
|
2005-07-30 08:12:19 +08:00
|
|
|
const Loop *L = S->getLoop();
|
|
|
|
|
2009-06-14 00:25:49 +08:00
|
|
|
// First check for an existing canonical IV in a suitable type.
|
2014-04-15 12:59:12 +08:00
|
|
|
PHINode *CanonicalIV = nullptr;
|
2009-06-14 00:25:49 +08:00
|
|
|
if (PHINode *PN = L->getCanonicalInductionVariable())
|
2010-07-21 00:46:58 +08:00
|
|
|
if (SE.getTypeSizeInBits(PN->getType()) >= SE.getTypeSizeInBits(Ty))
|
2009-06-14 00:25:49 +08:00
|
|
|
CanonicalIV = PN;
|
|
|
|
|
|
|
|
// Rewrite an AddRec in terms of the canonical induction variable, if
|
|
|
|
// its type is more narrow.
|
|
|
|
if (CanonicalIV &&
|
|
|
|
SE.getTypeSizeInBits(CanonicalIV->getType()) >
|
|
|
|
SE.getTypeSizeInBits(Ty)) {
|
2010-03-18 09:17:13 +08:00
|
|
|
SmallVector<const SCEV *, 4> NewOps(S->getNumOperands());
|
|
|
|
for (unsigned i = 0, e = S->getNumOperands(); i != e; ++i)
|
|
|
|
NewOps[i] = SE.getAnyExtendExpr(S->op_begin()[i], CanonicalIV->getType());
|
2011-03-15 00:50:06 +08:00
|
|
|
Value *V = expand(SE.getAddRecExpr(NewOps, S->getLoop(),
|
2013-07-14 11:10:08 +08:00
|
|
|
S->getNoWrapFlags(SCEV::FlagNW)));
|
2015-10-28 03:48:28 +08:00
|
|
|
BasicBlock::iterator NewInsertPt =
|
|
|
|
findInsertPointAfter(cast<Instruction>(V), Builder.GetInsertBlock());
|
2014-04-15 12:59:12 +08:00
|
|
|
V = expandCodeFor(SE.getTruncateExpr(SE.getUnknown(V), Ty), nullptr,
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
&*NewInsertPt);
|
2009-06-14 00:25:49 +08:00
|
|
|
return V;
|
|
|
|
}
|
|
|
|
|
2005-07-30 08:12:19 +08:00
|
|
|
// {X,+,F} --> X + {0,+,F}
|
2008-06-19 00:23:07 +08:00
|
|
|
if (!S->getStart()->isZero()) {
|
2010-03-18 09:17:13 +08:00
|
|
|
SmallVector<const SCEV *, 4> NewOps(S->op_begin(), S->op_end());
|
2010-05-04 06:09:21 +08:00
|
|
|
NewOps[0] = SE.getConstant(Ty, 0);
|
2013-07-14 11:10:08 +08:00
|
|
|
const SCEV *Rest = SE.getAddRecExpr(NewOps, L,
|
|
|
|
S->getNoWrapFlags(SCEV::FlagNW));
|
2009-05-25 02:06:31 +08:00
|
|
|
|
|
|
|
// Turn things like ptrtoint+arithmetic+inttoptr into GEP. See the
|
|
|
|
// comments on expandAddToGEP for details.
|
2009-08-19 00:46:41 +08:00
|
|
|
const SCEV *Base = S->getStart();
|
|
|
|
const SCEV *RestArray[1] = { Rest };
|
|
|
|
// Dig into the expression to find the pointer base for a GEP.
|
|
|
|
ExposePointerBase(Base, RestArray[0], SE);
|
|
|
|
// If we found a pointer, expand the AddRec with a GEP.
|
2011-07-18 12:54:35 +08:00
|
|
|
if (PointerType *PTy = dyn_cast<PointerType>(Base->getType())) {
|
2009-08-19 00:46:41 +08:00
|
|
|
// Make sure the Base isn't something exotic, such as a multiplied
|
|
|
|
// or divided pointer value. In those cases, the result type isn't
|
|
|
|
// actually a pointer type.
|
|
|
|
if (!isa<SCEVMulExpr>(Base) && !isa<SCEVUDivExpr>(Base)) {
|
|
|
|
Value *StartV = expand(Base);
|
|
|
|
assert(StartV->getType() == PTy && "Pointer type mismatch for GEP!");
|
|
|
|
return expandAddToGEP(RestArray, RestArray+1, PTy, Ty, StartV);
|
2009-05-25 02:06:31 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-06-24 09:18:18 +08:00
|
|
|
// Just do a normal add. Pre-expand the operands to suppress folding.
|
2016-06-20 18:19:04 +08:00
|
|
|
//
|
|
|
|
// The LHS and RHS values are factored out of the expand call to make the
|
|
|
|
// output independent of the argument evaluation order.
|
|
|
|
const SCEV *AddExprLHS = SE.getUnknown(expand(S->getStart()));
|
|
|
|
const SCEV *AddExprRHS = SE.getUnknown(expand(Rest));
|
|
|
|
return expand(SE.getAddExpr(AddExprLHS, AddExprRHS));
|
2005-07-30 08:12:19 +08:00
|
|
|
}
|
|
|
|
|
2010-07-27 02:28:14 +08:00
|
|
|
// If we don't yet have a canonical IV, create one.
|
|
|
|
if (!CanonicalIV) {
|
2005-07-30 08:12:19 +08:00
|
|
|
// Create and insert the PHI node for the induction variable in the
|
|
|
|
// specified loop.
|
|
|
|
BasicBlock *Header = L->getHeader();
|
2011-03-30 19:19:20 +08:00
|
|
|
pred_iterator HPB = pred_begin(Header), HPE = pred_end(Header);
|
2011-03-30 19:28:46 +08:00
|
|
|
CanonicalIV = PHINode::Create(Ty, std::distance(HPB, HPE), "indvar",
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
&Header->front());
|
2010-07-27 02:28:14 +08:00
|
|
|
rememberInstruction(CanonicalIV);
|
2005-07-30 08:12:19 +08:00
|
|
|
|
Fix SCEVExpander creating distinct duplicate PHI entries
This fixes SCEVExpander so that it does not create multiple distinct induction
variables for duplicate PHI entries. Specifically, given some code like this:
do.body6: ; preds = %do.body6, %do.body6, %if.then5
%end.0 = phi i8* [ undef, %if.then5 ], [ %incdec.ptr, %do.body6 ], [ %incdec.ptr, %do.body6 ]
...
Note that it is legal to have multiple entries for a basic block so long as the
associated value is the same. So the above input is okay, but expanding an
AddRec in this loop could produce code like this:
do.body6: ; preds = %do.body6, %do.body6, %if.then5
%indvar = phi i64 [ %indvar.next, %do.body6 ], [ %indvar.next1, %do.body6 ], [ 0, %if.then5 ]
%end.0 = phi i8* [ undef, %if.then5 ], [ %incdec.ptr, %do.body6 ], [ %incdec.ptr, %do.body6 ]
...
%indvar.next = add i64 %indvar, 1
%indvar.next1 = add i64 %indvar, 1
And this is not legal because there are two PHI entries for %do.body6 each with
a distinct value.
Unfortunately, I don't have an in-tree test case.
llvm-svn: 188614
2013-08-18 08:16:23 +08:00
|
|
|
SmallSet<BasicBlock *, 4> PredSeen;
|
2009-07-25 07:12:02 +08:00
|
|
|
Constant *One = ConstantInt::get(Ty, 1);
|
2011-03-30 19:19:20 +08:00
|
|
|
for (pred_iterator HPI = HPB; HPI != HPE; ++HPI) {
|
2010-07-09 23:40:10 +08:00
|
|
|
BasicBlock *HP = *HPI;
|
2014-11-19 15:49:26 +08:00
|
|
|
if (!PredSeen.insert(HP).second) {
|
2014-08-01 03:13:38 +08:00
|
|
|
// There must be an incoming value for each predecessor, even the
|
|
|
|
// duplicates!
|
|
|
|
CanonicalIV->addIncoming(CanonicalIV->getIncomingValueForBlock(HP), HP);
|
Fix SCEVExpander creating distinct duplicate PHI entries
This fixes SCEVExpander so that it does not create multiple distinct induction
variables for duplicate PHI entries. Specifically, given some code like this:
do.body6: ; preds = %do.body6, %do.body6, %if.then5
%end.0 = phi i8* [ undef, %if.then5 ], [ %incdec.ptr, %do.body6 ], [ %incdec.ptr, %do.body6 ]
...
Note that it is legal to have multiple entries for a basic block so long as the
associated value is the same. So the above input is okay, but expanding an
AddRec in this loop could produce code like this:
do.body6: ; preds = %do.body6, %do.body6, %if.then5
%indvar = phi i64 [ %indvar.next, %do.body6 ], [ %indvar.next1, %do.body6 ], [ 0, %if.then5 ]
%end.0 = phi i8* [ undef, %if.then5 ], [ %incdec.ptr, %do.body6 ], [ %incdec.ptr, %do.body6 ]
...
%indvar.next = add i64 %indvar, 1
%indvar.next1 = add i64 %indvar, 1
And this is not legal because there are two PHI entries for %do.body6 each with
a distinct value.
Unfortunately, I don't have an in-tree test case.
llvm-svn: 188614
2013-08-18 08:16:23 +08:00
|
|
|
continue;
|
2014-08-01 03:13:38 +08:00
|
|
|
}
|
Fix SCEVExpander creating distinct duplicate PHI entries
This fixes SCEVExpander so that it does not create multiple distinct induction
variables for duplicate PHI entries. Specifically, given some code like this:
do.body6: ; preds = %do.body6, %do.body6, %if.then5
%end.0 = phi i8* [ undef, %if.then5 ], [ %incdec.ptr, %do.body6 ], [ %incdec.ptr, %do.body6 ]
...
Note that it is legal to have multiple entries for a basic block so long as the
associated value is the same. So the above input is okay, but expanding an
AddRec in this loop could produce code like this:
do.body6: ; preds = %do.body6, %do.body6, %if.then5
%indvar = phi i64 [ %indvar.next, %do.body6 ], [ %indvar.next1, %do.body6 ], [ 0, %if.then5 ]
%end.0 = phi i8* [ undef, %if.then5 ], [ %incdec.ptr, %do.body6 ], [ %incdec.ptr, %do.body6 ]
...
%indvar.next = add i64 %indvar, 1
%indvar.next1 = add i64 %indvar, 1
And this is not legal because there are two PHI entries for %do.body6 each with
a distinct value.
Unfortunately, I don't have an in-tree test case.
llvm-svn: 188614
2013-08-18 08:16:23 +08:00
|
|
|
|
2010-07-09 23:40:10 +08:00
|
|
|
if (L->contains(HP)) {
|
2010-01-20 06:26:02 +08:00
|
|
|
// Insert a unit add instruction right before the terminator
|
|
|
|
// corresponding to the back-edge.
|
2010-07-27 02:28:14 +08:00
|
|
|
Instruction *Add = BinaryOperator::CreateAdd(CanonicalIV, One,
|
|
|
|
"indvar.next",
|
|
|
|
HP->getTerminator());
|
2011-06-23 04:56:56 +08:00
|
|
|
Add->setDebugLoc(HP->getTerminator()->getDebugLoc());
|
2010-01-21 10:09:26 +08:00
|
|
|
rememberInstruction(Add);
|
2010-07-27 02:28:14 +08:00
|
|
|
CanonicalIV->addIncoming(Add, HP);
|
2009-09-28 01:46:40 +08:00
|
|
|
} else {
|
2010-07-27 02:28:14 +08:00
|
|
|
CanonicalIV->addIncoming(Constant::getNullValue(Ty), HP);
|
2009-09-28 01:46:40 +08:00
|
|
|
}
|
2010-07-09 23:40:10 +08:00
|
|
|
}
|
2005-07-30 08:12:19 +08:00
|
|
|
}
|
|
|
|
|
2010-07-27 02:28:14 +08:00
|
|
|
// {0,+,1} --> Insert a canonical induction variable into the loop!
|
|
|
|
if (S->isAffine() && S->getOperand(1)->isOne()) {
|
|
|
|
assert(Ty == SE.getEffectiveSCEVType(CanonicalIV->getType()) &&
|
|
|
|
"IVs with types different from the canonical IV should "
|
|
|
|
"already have been handled!");
|
|
|
|
return CanonicalIV;
|
|
|
|
}
|
|
|
|
|
2009-06-14 00:25:49 +08:00
|
|
|
// {0,+,F} --> {0,+,1} * F
|
2005-07-30 08:12:19 +08:00
|
|
|
|
Fix a problem that Nate noticed with LSR:
When inserting code for an addrec expression with a non-unit stride, be
more careful where we insert the multiply. In particular, insert the multiply
in the outermost loop we can, instead of the requested insertion point.
This allows LSR to notice the mul in the right loop, reducing it when it gets
to it. This allows it to reduce the multiply, where before it missed it.
This happens quite a bit in the test suite, for example, eliminating 2
multiplies in art, 3 in ammp, 4 in apsi, reducing from 1050 multiplies to
910 muls in galgel (!), from 877 to 859 in applu, and 36 to 30 in bzip2.
This speeds up galgel from 16.45s to 16.01s, applu from 14.21 to 13.94s and
fourinarow from 66.67s to 63.48s.
This implements Transforms/LoopStrengthReduce/nested-reduce.ll
llvm-svn: 24102
2005-10-30 14:24:33 +08:00
|
|
|
// If this is a simple linear addrec, emit it now as a special case.
|
2009-06-24 09:18:18 +08:00
|
|
|
if (S->isAffine()) // {0,+,F} --> i*F
|
|
|
|
return
|
|
|
|
expand(SE.getTruncateOrNoop(
|
2010-07-27 02:28:14 +08:00
|
|
|
SE.getMulExpr(SE.getUnknown(CanonicalIV),
|
2009-06-24 09:18:18 +08:00
|
|
|
SE.getNoopOrAnyExtend(S->getOperand(1),
|
2010-07-27 02:28:14 +08:00
|
|
|
CanonicalIV->getType())),
|
2009-06-24 09:18:18 +08:00
|
|
|
Ty));
|
2005-07-30 08:12:19 +08:00
|
|
|
|
|
|
|
// If this is a chain of recurrences, turn it into a closed form, using the
|
|
|
|
// folders, then expandCodeFor the closed form. This allows the folders to
|
|
|
|
// simplify the expression without having to build a bunch of special code
|
|
|
|
// into this folder.
|
2010-07-27 02:28:14 +08:00
|
|
|
const SCEV *IH = SE.getUnknown(CanonicalIV); // Get I as a "symbolic" SCEV.
|
2005-07-30 08:12:19 +08:00
|
|
|
|
2009-06-14 00:25:49 +08:00
|
|
|
// Promote S up to the canonical IV type, if the cast is foldable.
|
2009-07-08 01:06:11 +08:00
|
|
|
const SCEV *NewS = S;
|
2010-07-27 02:28:14 +08:00
|
|
|
const SCEV *Ext = SE.getNoopOrAnyExtend(S, CanonicalIV->getType());
|
2009-06-14 00:25:49 +08:00
|
|
|
if (isa<SCEVAddRecExpr>(Ext))
|
|
|
|
NewS = Ext;
|
|
|
|
|
2009-07-08 01:06:11 +08:00
|
|
|
const SCEV *V = cast<SCEVAddRecExpr>(NewS)->evaluateAtIteration(IH, SE);
|
2006-12-07 09:30:32 +08:00
|
|
|
//cerr << "Evaluated: " << *this << "\n to: " << *V << "\n";
|
2005-07-30 08:12:19 +08:00
|
|
|
|
2009-06-14 00:25:49 +08:00
|
|
|
// Truncate the result down to the original type, if needed.
|
2009-07-08 01:06:11 +08:00
|
|
|
const SCEV *T = SE.getTruncateOrNoop(V, Ty);
|
2009-06-23 06:08:45 +08:00
|
|
|
return expand(T);
|
2005-07-30 08:12:19 +08:00
|
|
|
}
|
2007-08-21 05:17:26 +08:00
|
|
|
|
2009-04-19 01:56:28 +08:00
|
|
|
Value *SCEVExpander::visitTruncateExpr(const SCEVTruncateExpr *S) {
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty = SE.getEffectiveSCEVType(S->getType());
|
2009-06-10 01:18:38 +08:00
|
|
|
Value *V = expandCodeFor(S->getOperand(),
|
|
|
|
SE.getEffectiveSCEVType(S->getOperand()->getType()));
|
2011-09-28 04:39:19 +08:00
|
|
|
Value *I = Builder.CreateTrunc(V, Ty);
|
2010-01-21 10:09:26 +08:00
|
|
|
rememberInstruction(I);
|
2009-05-02 01:13:31 +08:00
|
|
|
return I;
|
2008-06-23 03:09:18 +08:00
|
|
|
}
|
|
|
|
|
2009-04-19 01:56:28 +08:00
|
|
|
Value *SCEVExpander::visitZeroExtendExpr(const SCEVZeroExtendExpr *S) {
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty = SE.getEffectiveSCEVType(S->getType());
|
2009-06-10 01:18:38 +08:00
|
|
|
Value *V = expandCodeFor(S->getOperand(),
|
|
|
|
SE.getEffectiveSCEVType(S->getOperand()->getType()));
|
2011-09-28 04:39:19 +08:00
|
|
|
Value *I = Builder.CreateZExt(V, Ty);
|
2010-01-21 10:09:26 +08:00
|
|
|
rememberInstruction(I);
|
2009-05-02 01:13:31 +08:00
|
|
|
return I;
|
2008-06-23 03:09:18 +08:00
|
|
|
}
|
|
|
|
|
2009-04-19 01:56:28 +08:00
|
|
|
Value *SCEVExpander::visitSignExtendExpr(const SCEVSignExtendExpr *S) {
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty = SE.getEffectiveSCEVType(S->getType());
|
2009-06-10 01:18:38 +08:00
|
|
|
Value *V = expandCodeFor(S->getOperand(),
|
|
|
|
SE.getEffectiveSCEVType(S->getOperand()->getType()));
|
2011-09-28 04:39:19 +08:00
|
|
|
Value *I = Builder.CreateSExt(V, Ty);
|
2010-01-21 10:09:26 +08:00
|
|
|
rememberInstruction(I);
|
2009-05-02 01:13:31 +08:00
|
|
|
return I;
|
2008-06-23 03:09:18 +08:00
|
|
|
}
|
|
|
|
|
2009-04-19 01:56:28 +08:00
|
|
|
Value *SCEVExpander::visitSMaxExpr(const SCEVSMaxExpr *S) {
|
2009-07-15 04:57:04 +08:00
|
|
|
Value *LHS = expand(S->getOperand(S->getNumOperands()-1));
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty = LHS->getType();
|
2009-07-15 04:57:04 +08:00
|
|
|
for (int i = S->getNumOperands()-2; i >= 0; --i) {
|
|
|
|
// In the case of mixed integer and pointer types, do the
|
|
|
|
// rest of the comparisons as integer.
|
|
|
|
if (S->getOperand(i)->getType() != Ty) {
|
|
|
|
Ty = SE.getEffectiveSCEVType(Ty);
|
|
|
|
LHS = InsertNoopCastOfTo(LHS, Ty);
|
|
|
|
}
|
2009-06-10 01:18:38 +08:00
|
|
|
Value *RHS = expandCodeFor(S->getOperand(i), Ty);
|
2011-09-28 04:39:19 +08:00
|
|
|
Value *ICmp = Builder.CreateICmpSGT(LHS, RHS);
|
2010-01-21 10:09:26 +08:00
|
|
|
rememberInstruction(ICmp);
|
2009-06-28 05:18:18 +08:00
|
|
|
Value *Sel = Builder.CreateSelect(ICmp, LHS, RHS, "smax");
|
2010-01-21 10:09:26 +08:00
|
|
|
rememberInstruction(Sel);
|
2009-05-02 01:13:31 +08:00
|
|
|
LHS = Sel;
|
2007-11-26 06:41:31 +08:00
|
|
|
}
|
2009-07-15 04:57:04 +08:00
|
|
|
// In the case of mixed integer and pointer types, cast the
|
|
|
|
// final result back to the pointer type.
|
|
|
|
if (LHS->getType() != S->getType())
|
|
|
|
LHS = InsertNoopCastOfTo(LHS, S->getType());
|
2007-11-26 06:41:31 +08:00
|
|
|
return LHS;
|
|
|
|
}
|
|
|
|
|
2009-04-19 01:56:28 +08:00
|
|
|
Value *SCEVExpander::visitUMaxExpr(const SCEVUMaxExpr *S) {
|
2009-07-15 04:57:04 +08:00
|
|
|
Value *LHS = expand(S->getOperand(S->getNumOperands()-1));
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty = LHS->getType();
|
2009-07-15 04:57:04 +08:00
|
|
|
for (int i = S->getNumOperands()-2; i >= 0; --i) {
|
|
|
|
// In the case of mixed integer and pointer types, do the
|
|
|
|
// rest of the comparisons as integer.
|
|
|
|
if (S->getOperand(i)->getType() != Ty) {
|
|
|
|
Ty = SE.getEffectiveSCEVType(Ty);
|
|
|
|
LHS = InsertNoopCastOfTo(LHS, Ty);
|
|
|
|
}
|
2009-06-10 01:18:38 +08:00
|
|
|
Value *RHS = expandCodeFor(S->getOperand(i), Ty);
|
2011-09-28 04:39:19 +08:00
|
|
|
Value *ICmp = Builder.CreateICmpUGT(LHS, RHS);
|
2010-01-21 10:09:26 +08:00
|
|
|
rememberInstruction(ICmp);
|
2009-06-28 05:18:18 +08:00
|
|
|
Value *Sel = Builder.CreateSelect(ICmp, LHS, RHS, "umax");
|
2010-01-21 10:09:26 +08:00
|
|
|
rememberInstruction(Sel);
|
2009-05-02 01:13:31 +08:00
|
|
|
LHS = Sel;
|
2008-02-20 14:48:22 +08:00
|
|
|
}
|
2009-07-15 04:57:04 +08:00
|
|
|
// In the case of mixed integer and pointer types, cast the
|
|
|
|
// final result back to the pointer type.
|
|
|
|
if (LHS->getType() != S->getType())
|
|
|
|
LHS = InsertNoopCastOfTo(LHS, S->getType());
|
2008-02-20 14:48:22 +08:00
|
|
|
return LHS;
|
|
|
|
}
|
|
|
|
|
2011-07-18 12:54:35 +08:00
|
|
|
Value *SCEVExpander::expandCodeFor(const SCEV *SH, Type *Ty,
|
2012-01-20 15:41:13 +08:00
|
|
|
Instruction *IP) {
|
2016-08-12 05:05:17 +08:00
|
|
|
setInsertPoint(IP);
|
2010-03-20 05:51:03 +08:00
|
|
|
return expandCodeFor(SH, Ty);
|
|
|
|
}
|
|
|
|
|
2011-07-18 12:54:35 +08:00
|
|
|
Value *SCEVExpander::expandCodeFor(const SCEV *SH, Type *Ty) {
|
2008-06-23 03:09:18 +08:00
|
|
|
// Expand the code for this SCEV.
|
2009-04-16 11:18:22 +08:00
|
|
|
Value *V = expand(SH);
|
2009-05-19 10:15:55 +08:00
|
|
|
if (Ty) {
|
|
|
|
assert(SE.getTypeSizeInBits(Ty) == SE.getTypeSizeInBits(SH->getType()) &&
|
|
|
|
"non-trivial casts should be done with the SCEVs directly!");
|
|
|
|
V = InsertNoopCastOfTo(V, Ty);
|
|
|
|
}
|
|
|
|
return V;
|
2008-06-23 03:09:18 +08:00
|
|
|
}
|
|
|
|
|
Recommit "Use ValueOffsetPair to enhance value reuse during SCEV expansion".
The fix for PR28705 will be committed consecutively.
In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion.
However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and
S1 = S2 + C_a
S3 = S2 + C_b
where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as
V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a
complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused
by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to
ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the
ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first
expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to
V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
llvm-svn: 278160
2016-08-10 04:37:50 +08:00
|
|
|
ScalarEvolution::ValueOffsetPair
|
|
|
|
SCEVExpander::FindValueInExprValueMap(const SCEV *S,
|
|
|
|
const Instruction *InsertPt) {
|
|
|
|
SetVector<ScalarEvolution::ValueOffsetPair> *Set = SE.getSCEVValues(S);
|
2016-02-16 14:46:58 +08:00
|
|
|
// If the expansion is not in CanonicalMode, and the SCEV contains any
|
|
|
|
// sub scAddRecExpr type SCEV, it is required to expand the SCEV literally.
|
|
|
|
if (CanonicalMode || !SE.containsAddRecurrence(S)) {
|
|
|
|
// If S is scConstant, it may be worse to reuse an existing Value.
|
|
|
|
if (S->getSCEVType() != scConstant && Set) {
|
|
|
|
// Choose a Value from the set which dominates the insertPt.
|
|
|
|
// insertPt should be inside the Value's parent loop so as not to break
|
|
|
|
// the LCSSA form.
|
Recommit "Use ValueOffsetPair to enhance value reuse during SCEV expansion".
The fix for PR28705 will be committed consecutively.
In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion.
However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and
S1 = S2 + C_a
S3 = S2 + C_b
where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as
V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a
complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused
by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to
ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the
ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first
expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to
V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
llvm-svn: 278160
2016-08-10 04:37:50 +08:00
|
|
|
for (auto const &VOPair : *Set) {
|
|
|
|
Value *V = VOPair.first;
|
|
|
|
ConstantInt *Offset = VOPair.second;
|
2016-02-16 14:46:58 +08:00
|
|
|
Instruction *EntInst = nullptr;
|
Recommit "Use ValueOffsetPair to enhance value reuse during SCEV expansion".
The fix for PR28705 will be committed consecutively.
In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion.
However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and
S1 = S2 + C_a
S3 = S2 + C_b
where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as
V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a
complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused
by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to
ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the
ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first
expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to
V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
llvm-svn: 278160
2016-08-10 04:37:50 +08:00
|
|
|
if (V && isa<Instruction>(V) && (EntInst = cast<Instruction>(V)) &&
|
|
|
|
S->getType() == V->getType() &&
|
2016-02-16 14:46:58 +08:00
|
|
|
EntInst->getFunction() == InsertPt->getFunction() &&
|
|
|
|
SE.DT.dominates(EntInst, InsertPt) &&
|
|
|
|
(SE.LI.getLoopFor(EntInst->getParent()) == nullptr ||
|
Recommit "Use ValueOffsetPair to enhance value reuse during SCEV expansion".
The fix for PR28705 will be committed consecutively.
In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion.
However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and
S1 = S2 + C_a
S3 = S2 + C_b
where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as
V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a
complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused
by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to
ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the
ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first
expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to
V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
llvm-svn: 278160
2016-08-10 04:37:50 +08:00
|
|
|
SE.LI.getLoopFor(EntInst->getParent())->contains(InsertPt)))
|
|
|
|
return {V, Offset};
|
2016-02-16 14:46:58 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
Recommit "Use ValueOffsetPair to enhance value reuse during SCEV expansion".
The fix for PR28705 will be committed consecutively.
In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion.
However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and
S1 = S2 + C_a
S3 = S2 + C_b
where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as
V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a
complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused
by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to
ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the
ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first
expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to
V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
llvm-svn: 278160
2016-08-10 04:37:50 +08:00
|
|
|
return {nullptr, nullptr};
|
2016-02-16 14:46:58 +08:00
|
|
|
}
|
|
|
|
|
[SCEV] Try to reuse existing value during SCEV expansion
Current SCEV expansion will expand SCEV as a sequence of operations
and doesn't utilize the value already existed. This will introduce
redundent computation which may not be cleaned up throughly by
following optimizations.
This patch introduces an ExprValueMap which is a map from SCEV to the
set of equal values with the same SCEV. When a SCEV is expanded, the
set of values is checked and reused whenever possible before generating
a sequence of operations.
The original commit triggered regressions in Polly tests. The regressions
exposed two problems which have been fixed in current version.
1. Polly will generate a new function based on the old one. To generate an
instruction for the new function, it builds SCEV for the old instruction,
applies some tranformation on the SCEV generated, then expands the transformed
SCEV and insert the expanded value into new function. Because SCEV expansion
may reuse value cached in ExprValueMap, the value in old function may be
inserted into new function, which is wrong.
In SCEVExpander::expand, there is a logic to check the cached value to
be used should dominate the insertion point. However, for the above
case, the check always passes. That is because the insertion point is
in a new function, which is unreachable from the old function. However
for unreachable node, DominatorTreeBase::dominates thinks it will be
dominated by any other node.
The fix is to simply add a check that the cached value to be used in
expansion should be in the same function as the insertion point instruction.
2. When the SCEV is of scConstant type, expanding it directly is cheaper than
reusing a normal value cached. Although in the cached value set in ExprValueMap,
there is a Constant type value, but it is not easy to find it out -- the cached
Value set is not sorted according to the potential cost. Existing reuse logic
in SCEVExpander::expand simply chooses the first legal element from the cached
value set.
The fix is that when the SCEV is of scConstant type, don't try the reuse
logic. simply expand it.
Differential Revision: http://reviews.llvm.org/D12090
llvm-svn: 259736
2016-02-04 09:27:38 +08:00
|
|
|
// The expansion of SCEV will either reuse a previous Value in ExprValueMap,
|
|
|
|
// or expand the SCEV literally. Specifically, if the expansion is in LSRMode,
|
|
|
|
// and the SCEV contains any sub scAddRecExpr type SCEV, it will be expanded
|
|
|
|
// literally, to prevent LSR's transformed SCEV from being reverted. Otherwise,
|
|
|
|
// the expansion will try to reuse Value from ExprValueMap, and only when it
|
|
|
|
// fails, expand the SCEV literally.
|
2009-04-19 01:56:28 +08:00
|
|
|
Value *SCEVExpander::expand(const SCEV *S) {
|
2009-06-24 09:18:18 +08:00
|
|
|
// Compute an insertion point for this SCEV object. Hoist the instructions
|
|
|
|
// as far out in the loop nest as possible.
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
Instruction *InsertPt = &*Builder.GetInsertPoint();
|
2016-12-13 02:52:32 +08:00
|
|
|
for (Loop *L = SE.LI.getLoopFor(Builder.GetInsertBlock());;
|
|
|
|
L = L->getParentLoop())
|
|
|
|
if (SE.isLoopInvariant(S, L)) {
|
|
|
|
if (!L) break;
|
|
|
|
if (BasicBlock *Preheader = L->getLoopPreheader())
|
|
|
|
InsertPt = Preheader->getTerminator();
|
|
|
|
else {
|
|
|
|
// LSR sets the insertion point for AddRec start/step values to the
|
|
|
|
// block start to simplify value reuse, even though it's an invalid
|
|
|
|
// position. SCEVExpander must correct for this in all cases.
|
|
|
|
InsertPt = &*L->getHeader()->getFirstInsertionPt();
|
2012-01-20 15:41:13 +08:00
|
|
|
}
|
2016-12-13 02:52:32 +08:00
|
|
|
} else {
|
|
|
|
// If the SCEV is computable at this level, insert it into the header
|
|
|
|
// after the PHIs (and after any other instructions that we've inserted
|
|
|
|
// there) so that it is guaranteed to dominate any user inside the loop.
|
|
|
|
if (L && SE.hasComputableLoopEvolution(S, L) && !PostIncLoops.count(L))
|
|
|
|
InsertPt = &*L->getHeader()->getFirstInsertionPt();
|
|
|
|
while (InsertPt->getIterator() != Builder.GetInsertPoint() &&
|
|
|
|
(isInsertedInstruction(InsertPt) ||
|
|
|
|
isa<DbgInfoIntrinsic>(InsertPt))) {
|
|
|
|
InsertPt = &*std::next(InsertPt->getIterator());
|
2016-11-11 01:55:41 +08:00
|
|
|
}
|
2016-12-13 02:52:32 +08:00
|
|
|
break;
|
|
|
|
}
|
2009-06-24 09:18:18 +08:00
|
|
|
|
2009-06-27 06:53:46 +08:00
|
|
|
// Check to see if we already expanded this here.
|
2015-11-22 07:20:10 +08:00
|
|
|
auto I = InsertedExpressions.find(std::make_pair(S, InsertPt));
|
2009-06-28 05:18:18 +08:00
|
|
|
if (I != InsertedExpressions.end())
|
2009-06-27 06:53:46 +08:00
|
|
|
return I->second;
|
2009-06-28 05:18:18 +08:00
|
|
|
|
2016-06-02 04:03:09 +08:00
|
|
|
SCEVInsertPointGuard Guard(Builder, this);
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
Builder.SetInsertPoint(InsertPt);
|
2009-06-27 06:53:46 +08:00
|
|
|
|
|
|
|
// Expand the expression into instructions.
|
Recommit "Use ValueOffsetPair to enhance value reuse during SCEV expansion".
The fix for PR28705 will be committed consecutively.
In D12090, the ExprValueMap was added to reuse existing value during SCEV expansion.
However, const folding and sext/zext distribution can make the reuse still difficult.
A simplified case is: suppose we know S1 expands to V1 in ExprValueMap, and
S1 = S2 + C_a
S3 = S2 + C_b
where C_a and C_b are different SCEVConstants. Then we'd like to expand S3 as
V1 - C_a + C_b instead of expanding S2 literally. It is helpful when S2 is a
complex SCEV expr and S2 has no entry in ExprValueMap, which is usually caused
by the fact that S3 is generated from S1 after const folding.
In order to do that, we represent ExprValueMap as a mapping from SCEV to
ValueOffsetPair. We will save both S1->{V1, 0} and S2->{V1, C_a} into the
ExprValueMap when we create SCEV for V1. When S3 is expanded, it will first
expand S2 to V1 - C_a because of S2->{V1, C_a} in the map, then expand S3 to
V1 - C_a + C_b.
Differential Revision: https://reviews.llvm.org/D21313
llvm-svn: 278160
2016-08-10 04:37:50 +08:00
|
|
|
ScalarEvolution::ValueOffsetPair VO = FindValueInExprValueMap(S, InsertPt);
|
|
|
|
Value *V = VO.first;
|
2016-02-16 14:46:58 +08:00
|
|
|
|
[SCEV] Try to reuse existing value during SCEV expansion
Current SCEV expansion will expand SCEV as a sequence of operations
and doesn't utilize the value already existed. This will introduce
redundent computation which may not be cleaned up throughly by
following optimizations.
This patch introduces an ExprValueMap which is a map from SCEV to the
set of equal values with the same SCEV. When a SCEV is expanded, the
set of values is checked and reused whenever possible before generating
a sequence of operations.
The original commit triggered regressions in Polly tests. The regressions
exposed two problems which have been fixed in current version.
1. Polly will generate a new function based on the old one. To generate an
instruction for the new function, it builds SCEV for the old instruction,
applies some tranformation on the SCEV generated, then expands the transformed
SCEV and insert the expanded value into new function. Because SCEV expansion
may reuse value cached in ExprValueMap, the value in old function may be
inserted into new function, which is wrong.
In SCEVExpander::expand, there is a logic to check the cached value to
be used should dominate the insertion point. However, for the above
case, the check always passes. That is because the insertion point is
in a new function, which is unreachable from the old function. However
for unreachable node, DominatorTreeBase::dominates thinks it will be
dominated by any other node.
The fix is to simply add a check that the cached value to be used in
expansion should be in the same function as the insertion point instruction.
2. When the SCEV is of scConstant type, expanding it directly is cheaper than
reusing a normal value cached. Although in the cached value set in ExprValueMap,
there is a Constant type value, but it is not easy to find it out -- the cached
Value set is not sorted according to the potential cost. Existing reuse logic
in SCEVExpander::expand simply chooses the first legal element from the cached
value set.
The fix is that when the SCEV is of scConstant type, don't try the reuse
logic. simply expand it.
Differential Revision: http://reviews.llvm.org/D12090
llvm-svn: 259736
2016-02-04 09:27:38 +08:00
|
|
|
if (!V)
|
|
|
|
V = visit(S);
|
2016-09-14 12:39:50 +08:00
|
|
|
else if (VO.second) {
|
|
|
|
if (PointerType *Vty = dyn_cast<PointerType>(V->getType())) {
|
|
|
|
Type *Ety = Vty->getPointerElementType();
|
|
|
|
int64_t Offset = VO.second->getSExtValue();
|
|
|
|
int64_t ESize = SE.getTypeSizeInBits(Ety);
|
|
|
|
if ((Offset * 8) % ESize == 0) {
|
|
|
|
ConstantInt *Idx =
|
|
|
|
ConstantInt::getSigned(VO.second->getType(), -(Offset * 8) / ESize);
|
|
|
|
V = Builder.CreateGEP(Ety, V, Idx, "scevgep");
|
|
|
|
} else {
|
|
|
|
ConstantInt *Idx =
|
|
|
|
ConstantInt::getSigned(VO.second->getType(), -Offset);
|
|
|
|
unsigned AS = Vty->getAddressSpace();
|
|
|
|
V = Builder.CreateBitCast(V, Type::getInt8PtrTy(SE.getContext(), AS));
|
|
|
|
V = Builder.CreateGEP(Type::getInt8Ty(SE.getContext()), V, Idx,
|
|
|
|
"uglygep");
|
|
|
|
V = Builder.CreateBitCast(V, Vty);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
V = Builder.CreateSub(V, VO.second);
|
|
|
|
}
|
|
|
|
}
|
2009-06-27 06:53:46 +08:00
|
|
|
// Remember the expanded value for this SCEV at this location.
|
2011-10-14 05:55:29 +08:00
|
|
|
//
|
|
|
|
// This is independent of PostIncLoops. The mapped value simply materializes
|
|
|
|
// the expression at this insertion point. If the mapped value happened to be
|
2013-12-05 13:44:44 +08:00
|
|
|
// a postinc expansion, it could be reused by a non-postinc user, but only if
|
2011-10-14 05:55:29 +08:00
|
|
|
// its insertion point was already at the head of the loop.
|
|
|
|
InsertedExpressions[std::make_pair(S, InsertPt)] = V;
|
2007-08-21 05:17:26 +08:00
|
|
|
return V;
|
|
|
|
}
|
2009-06-06 00:35:53 +08:00
|
|
|
|
2010-02-14 11:12:47 +08:00
|
|
|
void SCEVExpander::rememberInstruction(Value *I) {
|
2010-06-05 08:33:07 +08:00
|
|
|
if (!PostIncLoops.empty())
|
|
|
|
InsertedPostIncValues.insert(I);
|
|
|
|
else
|
2010-02-14 11:12:47 +08:00
|
|
|
InsertedValues.insert(I);
|
|
|
|
}
|
|
|
|
|
2009-06-06 00:35:53 +08:00
|
|
|
/// getOrInsertCanonicalInductionVariable - This method returns the
|
|
|
|
/// canonical induction variable of the specified type for the specified
|
|
|
|
/// loop (inserting one if there is none). A canonical induction variable
|
|
|
|
/// starts at zero and steps by one on each iteration.
|
2010-07-21 00:44:52 +08:00
|
|
|
PHINode *
|
2009-06-06 00:35:53 +08:00
|
|
|
SCEVExpander::getOrInsertCanonicalInductionVariable(const Loop *L,
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Ty) {
|
2010-02-16 00:12:20 +08:00
|
|
|
assert(Ty->isIntegerTy() && "Can only insert integer induction variables!");
|
2010-07-21 00:46:58 +08:00
|
|
|
|
|
|
|
// Build a SCEV for {0,+,1}<L>.
|
2011-03-15 00:50:06 +08:00
|
|
|
// Conservatively use FlagAnyWrap for now.
|
2010-05-04 06:09:21 +08:00
|
|
|
const SCEV *H = SE.getAddRecExpr(SE.getConstant(Ty, 0),
|
2011-03-15 00:50:06 +08:00
|
|
|
SE.getConstant(Ty, 1), L, SCEV::FlagAnyWrap);
|
2010-07-21 00:46:58 +08:00
|
|
|
|
|
|
|
// Emit code for it.
|
2016-06-02 04:03:09 +08:00
|
|
|
SCEVInsertPointGuard Guard(Builder, this);
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
PHINode *V =
|
|
|
|
cast<PHINode>(expandCodeFor(H, nullptr, &L->getHeader()->front()));
|
2010-07-21 00:46:58 +08:00
|
|
|
|
2009-06-24 09:18:18 +08:00
|
|
|
return V;
|
2009-06-06 00:35:53 +08:00
|
|
|
}
|
2011-10-11 10:28:51 +08:00
|
|
|
|
|
|
|
/// replaceCongruentIVs - Check for congruent phis in this loop header and
|
|
|
|
/// replace them with their most canonical representative. Return the number of
|
|
|
|
/// phis eliminated.
|
|
|
|
///
|
|
|
|
/// This does not depend on any SCEVExpander state but should be used in
|
|
|
|
/// the same context that SCEVExpander is used.
|
2017-05-02 01:07:49 +08:00
|
|
|
unsigned
|
|
|
|
SCEVExpander::replaceCongruentIVs(Loop *L, const DominatorTree *DT,
|
|
|
|
SmallVectorImpl<WeakTrackingVH> &DeadInsts,
|
|
|
|
const TargetTransformInfo *TTI) {
|
2012-01-07 09:12:09 +08:00
|
|
|
// Find integer phis in order of increasing width.
|
|
|
|
SmallVector<PHINode*, 8> Phis;
|
2015-11-22 07:20:10 +08:00
|
|
|
for (auto &I : *L->getHeader()) {
|
|
|
|
if (auto *PN = dyn_cast<PHINode>(&I))
|
|
|
|
Phis.push_back(PN);
|
|
|
|
else
|
|
|
|
break;
|
2012-01-07 09:12:09 +08:00
|
|
|
}
|
2015-11-22 07:20:10 +08:00
|
|
|
|
Switch the SCEV expander and LoopStrengthReduce to use
TargetTransformInfo rather than TargetLowering, removing one of the
primary instances of the layering violation of Transforms depending
directly on Target.
This is a really big deal because LSR used to be a "special" pass that
could only be tested fully using llc and by looking at the full output
of it. It also couldn't run with any other loop passes because it had to
be created by the backend. No longer is this true. LSR is now just
a normal pass and we should probably lift the creation of LSR out of
lib/CodeGen/Passes.cpp and into the PassManagerBuilder. =] I've not done
this, or updated all of the tests to use opt and a triple, because
I suspect someone more familiar with LSR would do a better job. This
change should be essentially without functional impact for normal
compilations, and only change behvaior of targetless compilations.
The conversion required changing all of the LSR code to refer to the TTI
interfaces, which fortunately are very similar to TargetLowering's
interfaces. However, it also allowed us to *always* expect to have some
implementation around. I've pushed that simplification through the pass,
and leveraged it to simplify code somewhat. It required some test
updates for one of two things: either we used to skip some checks
altogether but now we get the default "no" answer for them, or we used
to have no information about the target and now we do have some.
I've also started the process of removing AddrMode, as the TTI interface
doesn't use it any longer. In some cases this simplifies code, and in
others it adds some complexity, but I think it's not a bad tradeoff even
there. Subsequent patches will try to clean this up even further and use
other (more appropriate) abstractions.
Yet again, almost all of the formatting changes brought to you by
clang-format. =]
llvm-svn: 171735
2013-01-07 22:41:08 +08:00
|
|
|
if (TTI)
|
2014-03-08 05:35:39 +08:00
|
|
|
std::sort(Phis.begin(), Phis.end(), [](Value *LHS, Value *RHS) {
|
|
|
|
// Put pointers at the back and make sure pointer < pointer = false.
|
|
|
|
if (!LHS->getType()->isIntegerTy() || !RHS->getType()->isIntegerTy())
|
|
|
|
return RHS->getType()->isIntegerTy() && !LHS->getType()->isIntegerTy();
|
|
|
|
return RHS->getType()->getPrimitiveSizeInBits() <
|
|
|
|
LHS->getType()->getPrimitiveSizeInBits();
|
|
|
|
});
|
2012-01-07 09:12:09 +08:00
|
|
|
|
2011-10-11 10:28:51 +08:00
|
|
|
unsigned NumElim = 0;
|
|
|
|
DenseMap<const SCEV *, PHINode *> ExprToIVMap;
|
2015-06-19 09:53:21 +08:00
|
|
|
// Process phis from wide to narrow. Map wide phis to their truncation
|
2012-01-07 09:12:09 +08:00
|
|
|
// so narrow phis can reuse them.
|
2015-11-22 07:20:10 +08:00
|
|
|
for (PHINode *Phi : Phis) {
|
2015-11-04 00:27:04 +08:00
|
|
|
auto SimplifyPHINode = [&](PHINode *PN) -> Value * {
|
2017-04-29 03:55:38 +08:00
|
|
|
if (Value *V = SimplifyInstruction(PN, {DL, &SE.TLI, &SE.DT, &SE.AC}))
|
2015-11-04 00:27:04 +08:00
|
|
|
return V;
|
|
|
|
if (!SE.isSCEVable(PN->getType()))
|
|
|
|
return nullptr;
|
|
|
|
auto *Const = dyn_cast<SCEVConstant>(SE.getSCEV(PN));
|
|
|
|
if (!Const)
|
|
|
|
return nullptr;
|
|
|
|
return Const->getValue();
|
|
|
|
};
|
|
|
|
|
2012-10-20 00:37:30 +08:00
|
|
|
// Fold constant phis. They may be congruent to other constant phis and
|
|
|
|
// would confuse the logic below that expects proper IVs.
|
2015-11-04 00:27:04 +08:00
|
|
|
if (Value *V = SimplifyPHINode(Phi)) {
|
|
|
|
if (V->getType() != Phi->getType())
|
|
|
|
continue;
|
2012-10-20 00:37:30 +08:00
|
|
|
Phi->replaceAllUsesWith(V);
|
2015-05-30 03:43:39 +08:00
|
|
|
DeadInsts.emplace_back(Phi);
|
2012-10-20 00:37:30 +08:00
|
|
|
++NumElim;
|
|
|
|
DEBUG_WITH_TYPE(DebugType, dbgs()
|
|
|
|
<< "INDVARS: Eliminated constant iv: " << *Phi << '\n');
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2011-10-11 10:28:51 +08:00
|
|
|
if (!SE.isSCEVable(Phi->getType()))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
PHINode *&OrigPhiRef = ExprToIVMap[SE.getSCEV(Phi)];
|
|
|
|
if (!OrigPhiRef) {
|
|
|
|
OrigPhiRef = Phi;
|
2016-05-10 08:32:31 +08:00
|
|
|
if (Phi->getType()->isIntegerTy() && TTI &&
|
|
|
|
TTI->isTruncateFree(Phi->getType(), Phis.back()->getType())) {
|
2012-01-07 09:12:09 +08:00
|
|
|
// This phi can be freely truncated to the narrowest phi type. Map the
|
|
|
|
// truncated expression to it so it will be reused for narrow types.
|
|
|
|
const SCEV *TruncExpr =
|
|
|
|
SE.getTruncateExpr(SE.getSCEV(Phi), Phis.back()->getType());
|
|
|
|
ExprToIVMap[TruncExpr] = Phi;
|
|
|
|
}
|
2011-10-11 10:28:51 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2012-01-07 09:12:09 +08:00
|
|
|
// Replacing a pointer phi with an integer phi or vice-versa doesn't make
|
|
|
|
// sense.
|
|
|
|
if (OrigPhiRef->getType()->isPointerTy() != Phi->getType()->isPointerTy())
|
2011-10-11 10:28:51 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
if (BasicBlock *LatchBlock = L->getLoopLatch()) {
|
2016-05-12 01:41:41 +08:00
|
|
|
Instruction *OrigInc = dyn_cast<Instruction>(
|
|
|
|
OrigPhiRef->getIncomingValueForBlock(LatchBlock));
|
2011-10-11 10:28:51 +08:00
|
|
|
Instruction *IsomorphicInc =
|
2016-05-12 01:41:41 +08:00
|
|
|
dyn_cast<Instruction>(Phi->getIncomingValueForBlock(LatchBlock));
|
|
|
|
|
|
|
|
if (OrigInc && IsomorphicInc) {
|
|
|
|
// If this phi has the same width but is more canonical, replace the
|
|
|
|
// original with it. As part of the "more canonical" determination,
|
|
|
|
// respect a prior decision to use an IV chain.
|
|
|
|
if (OrigPhiRef->getType() == Phi->getType() &&
|
|
|
|
!(ChainedPhis.count(Phi) ||
|
|
|
|
isExpandedAddRecExprPHI(OrigPhiRef, OrigInc, L)) &&
|
|
|
|
(ChainedPhis.count(Phi) ||
|
|
|
|
isExpandedAddRecExprPHI(Phi, IsomorphicInc, L))) {
|
|
|
|
std::swap(OrigPhiRef, Phi);
|
|
|
|
std::swap(OrigInc, IsomorphicInc);
|
|
|
|
}
|
|
|
|
// Replacing the congruent phi is sufficient because acyclic
|
|
|
|
// redundancy elimination, CSE/GVN, should handle the
|
|
|
|
// rest. However, once SCEV proves that a phi is congruent,
|
|
|
|
// it's often the head of an IV user cycle that is isomorphic
|
|
|
|
// with the original phi. It's worth eagerly cleaning up the
|
|
|
|
// common case of a single IV increment so that DeleteDeadPHIs
|
|
|
|
// can remove cycles that had postinc uses.
|
|
|
|
const SCEV *TruncExpr =
|
|
|
|
SE.getTruncateOrNoop(SE.getSCEV(OrigInc), IsomorphicInc->getType());
|
|
|
|
if (OrigInc != IsomorphicInc &&
|
|
|
|
TruncExpr == SE.getSCEV(IsomorphicInc) &&
|
|
|
|
SE.LI.replacementPreservesLCSSAForm(IsomorphicInc, OrigInc) &&
|
|
|
|
hoistIVInc(OrigInc, IsomorphicInc)) {
|
|
|
|
DEBUG_WITH_TYPE(DebugType,
|
|
|
|
dbgs() << "INDVARS: Eliminated congruent iv.inc: "
|
|
|
|
<< *IsomorphicInc << '\n');
|
|
|
|
Value *NewInc = OrigInc;
|
|
|
|
if (OrigInc->getType() != IsomorphicInc->getType()) {
|
|
|
|
Instruction *IP = nullptr;
|
|
|
|
if (PHINode *PN = dyn_cast<PHINode>(OrigInc))
|
|
|
|
IP = &*PN->getParent()->getFirstInsertionPt();
|
|
|
|
else
|
|
|
|
IP = OrigInc->getNextNode();
|
|
|
|
|
|
|
|
IRBuilder<> Builder(IP);
|
|
|
|
Builder.SetCurrentDebugLocation(IsomorphicInc->getDebugLoc());
|
|
|
|
NewInc = Builder.CreateTruncOrBitCast(
|
|
|
|
OrigInc, IsomorphicInc->getType(), IVName);
|
|
|
|
}
|
|
|
|
IsomorphicInc->replaceAllUsesWith(NewInc);
|
|
|
|
DeadInsts.emplace_back(IsomorphicInc);
|
2012-01-07 09:12:09 +08:00
|
|
|
}
|
2011-10-11 10:28:51 +08:00
|
|
|
}
|
|
|
|
}
|
2016-05-10 08:32:31 +08:00
|
|
|
DEBUG_WITH_TYPE(DebugType, dbgs() << "INDVARS: Eliminated congruent iv: "
|
|
|
|
<< *Phi << '\n');
|
2011-10-11 10:28:51 +08:00
|
|
|
++NumElim;
|
2012-01-07 09:12:09 +08:00
|
|
|
Value *NewIV = OrigPhiRef;
|
|
|
|
if (OrigPhiRef->getType() != Phi->getType()) {
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
2015-10-10 08:53:03 +08:00
|
|
|
IRBuilder<> Builder(&*L->getHeader()->getFirstInsertionPt());
|
2012-01-07 09:12:09 +08:00
|
|
|
Builder.SetCurrentDebugLocation(Phi->getDebugLoc());
|
|
|
|
NewIV = Builder.CreateTruncOrBitCast(OrigPhiRef, Phi->getType(), IVName);
|
|
|
|
}
|
|
|
|
Phi->replaceAllUsesWith(NewIV);
|
2015-05-30 03:43:39 +08:00
|
|
|
DeadInsts.emplace_back(Phi);
|
2011-10-11 10:28:51 +08:00
|
|
|
}
|
|
|
|
return NumElim;
|
|
|
|
}
|
2012-07-14 07:33:10 +08:00
|
|
|
|
2016-08-10 04:40:03 +08:00
|
|
|
Value *SCEVExpander::getExactExistingExpansion(const SCEV *S,
|
|
|
|
const Instruction *At, Loop *L) {
|
|
|
|
Optional<ScalarEvolution::ValueOffsetPair> VO =
|
|
|
|
getRelatedExistingExpansion(S, At, L);
|
|
|
|
if (VO && VO.getValue().second == nullptr)
|
|
|
|
return VO.getValue().first;
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
Optional<ScalarEvolution::ValueOffsetPair>
|
|
|
|
SCEVExpander::getRelatedExistingExpansion(const SCEV *S, const Instruction *At,
|
|
|
|
Loop *L) {
|
2015-08-11 02:23:58 +08:00
|
|
|
using namespace llvm::PatternMatch;
|
|
|
|
|
2015-08-18 00:37:04 +08:00
|
|
|
SmallVector<BasicBlock *, 4> ExitingBlocks;
|
|
|
|
L->getExitingBlocks(ExitingBlocks);
|
2015-08-11 02:23:58 +08:00
|
|
|
|
2015-08-18 00:37:04 +08:00
|
|
|
// Look for suitable value in simple conditions at the loop exits.
|
|
|
|
for (BasicBlock *BB : ExitingBlocks) {
|
2015-08-11 02:23:58 +08:00
|
|
|
ICmpInst::Predicate Pred;
|
|
|
|
Instruction *LHS, *RHS;
|
|
|
|
BasicBlock *TrueBB, *FalseBB;
|
|
|
|
|
|
|
|
if (!match(BB->getTerminator(),
|
|
|
|
m_Br(m_ICmp(Pred, m_Instruction(LHS), m_Instruction(RHS)),
|
|
|
|
TrueBB, FalseBB)))
|
|
|
|
continue;
|
|
|
|
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
if (SE.getSCEV(LHS) == S && SE.DT.dominates(LHS, At))
|
2016-08-10 04:40:03 +08:00
|
|
|
return ScalarEvolution::ValueOffsetPair(LHS, nullptr);
|
2015-08-11 02:23:58 +08:00
|
|
|
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
llvm-svn: 245193
2015-08-17 10:08:17 +08:00
|
|
|
if (SE.getSCEV(RHS) == S && SE.DT.dominates(RHS, At))
|
2016-08-10 04:40:03 +08:00
|
|
|
return ScalarEvolution::ValueOffsetPair(RHS, nullptr);
|
2015-08-11 02:23:58 +08:00
|
|
|
}
|
|
|
|
|
2016-02-16 14:46:58 +08:00
|
|
|
// Use expand's logic which is used for reusing a previous Value in
|
|
|
|
// ExprValueMap.
|
2016-08-10 04:40:03 +08:00
|
|
|
ScalarEvolution::ValueOffsetPair VO = FindValueInExprValueMap(S, At);
|
|
|
|
if (VO.first)
|
|
|
|
return VO;
|
2016-02-16 14:46:58 +08:00
|
|
|
|
2015-08-11 02:23:58 +08:00
|
|
|
// There is potential to make this significantly smarter, but this simple
|
|
|
|
// heuristic already gets some interesting cases.
|
|
|
|
|
|
|
|
// Can not find suitable value.
|
2016-08-10 04:40:03 +08:00
|
|
|
return None;
|
2015-08-11 02:23:58 +08:00
|
|
|
}
|
|
|
|
|
2015-04-14 11:20:28 +08:00
|
|
|
bool SCEVExpander::isHighCostExpansionHelper(
|
2015-08-11 02:23:58 +08:00
|
|
|
const SCEV *S, Loop *L, const Instruction *At,
|
|
|
|
SmallPtrSetImpl<const SCEV *> &Processed) {
|
|
|
|
|
2016-11-20 21:47:59 +08:00
|
|
|
// If we can find an existing value for this scev available at the point "At"
|
2015-08-11 02:23:58 +08:00
|
|
|
// then consider the expression cheap.
|
2016-08-10 04:40:03 +08:00
|
|
|
if (At && getRelatedExistingExpansion(S, At, L))
|
2015-08-11 02:23:58 +08:00
|
|
|
return false;
|
2015-05-29 05:49:07 +08:00
|
|
|
|
|
|
|
// Zero/One operand expressions
|
|
|
|
switch (S->getSCEVType()) {
|
|
|
|
case scUnknown:
|
|
|
|
case scConstant:
|
|
|
|
return false;
|
|
|
|
case scTruncate:
|
2015-08-11 02:23:58 +08:00
|
|
|
return isHighCostExpansionHelper(cast<SCEVTruncateExpr>(S)->getOperand(),
|
|
|
|
L, At, Processed);
|
2015-05-29 05:49:07 +08:00
|
|
|
case scZeroExtend:
|
|
|
|
return isHighCostExpansionHelper(cast<SCEVZeroExtendExpr>(S)->getOperand(),
|
2015-08-11 02:23:58 +08:00
|
|
|
L, At, Processed);
|
2015-05-29 05:49:07 +08:00
|
|
|
case scSignExtend:
|
|
|
|
return isHighCostExpansionHelper(cast<SCEVSignExtendExpr>(S)->getOperand(),
|
2015-08-11 02:23:58 +08:00
|
|
|
L, At, Processed);
|
2015-05-29 05:49:07 +08:00
|
|
|
}
|
|
|
|
|
2015-04-14 11:20:28 +08:00
|
|
|
if (!Processed.insert(S).second)
|
|
|
|
return false;
|
|
|
|
|
2015-04-14 11:20:32 +08:00
|
|
|
if (auto *UDivExpr = dyn_cast<SCEVUDivExpr>(S)) {
|
|
|
|
// If the divisor is a power of two and the SCEV type fits in a native
|
2015-08-09 02:27:36 +08:00
|
|
|
// integer, consider the division cheap irrespective of whether it occurs in
|
2015-04-14 11:20:32 +08:00
|
|
|
// the user code since it can be lowered into a right shift.
|
|
|
|
if (auto *SC = dyn_cast<SCEVConstant>(UDivExpr->getRHS()))
|
2015-12-18 04:28:46 +08:00
|
|
|
if (SC->getAPInt().isPowerOf2()) {
|
2015-04-14 11:20:32 +08:00
|
|
|
const DataLayout &DL =
|
|
|
|
L->getHeader()->getParent()->getParent()->getDataLayout();
|
|
|
|
unsigned Width = cast<IntegerType>(UDivExpr->getType())->getBitWidth();
|
|
|
|
return DL.isIllegalInteger(Width);
|
|
|
|
}
|
|
|
|
|
|
|
|
// UDivExpr is very likely a UDiv that ScalarEvolution's HowFarToZero or
|
|
|
|
// HowManyLessThans produced to compute a precise expression, rather than a
|
|
|
|
// UDiv from the user's code. If we can't find a UDiv in the code with some
|
|
|
|
// simple searching, assume the former consider UDivExpr expensive to
|
|
|
|
// compute.
|
2015-04-14 11:20:28 +08:00
|
|
|
BasicBlock *ExitingBB = L->getExitingBlock();
|
|
|
|
if (!ExitingBB)
|
|
|
|
return true;
|
|
|
|
|
2015-08-18 00:37:04 +08:00
|
|
|
// At the beginning of this function we already tried to find existing value
|
|
|
|
// for plain 'S'. Now try to lookup 'S + 1' since it is common pattern
|
|
|
|
// involving division. This is just a simple search heuristic.
|
|
|
|
if (!At)
|
|
|
|
At = &ExitingBB->back();
|
2016-08-10 04:40:03 +08:00
|
|
|
if (!getRelatedExistingExpansion(
|
2015-08-18 00:37:04 +08:00
|
|
|
SE.getAddExpr(S, SE.getConstant(S->getType(), 1)), At, L))
|
2015-04-14 11:20:28 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-05-29 05:49:07 +08:00
|
|
|
// HowManyLessThans uses a Max expression whenever the loop is not guarded by
|
|
|
|
// the exit condition.
|
|
|
|
if (isa<SCEVSMaxExpr>(S) || isa<SCEVUMaxExpr>(S))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Recurse past nary expressions, which commonly occur in the
|
2015-04-14 11:20:28 +08:00
|
|
|
// BackedgeTakenCount. They may already exist in program code, and if not,
|
|
|
|
// they are not too expensive rematerialize.
|
2015-05-29 05:49:07 +08:00
|
|
|
if (const SCEVNAryExpr *NAry = dyn_cast<SCEVNAryExpr>(S)) {
|
2015-11-22 07:20:10 +08:00
|
|
|
for (auto *Op : NAry->operands())
|
|
|
|
if (isHighCostExpansionHelper(Op, L, At, Processed))
|
2015-04-14 11:20:28 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we haven't recognized an expensive SCEV pattern, assume it's an
|
|
|
|
// expression produced by program code.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
[SCEV][LV] Add SCEV Predicates and use them to re-implement stride versioning
Summary:
SCEV Predicates represent conditions that typically cannot be derived from
static analysis, but can be used to reduce SCEV expressions to forms which are
usable for different optimizers.
ScalarEvolution now has the rewriteUsingPredicate method which can simplify a
SCEV expression using a SCEVPredicateSet. The normal workflow of a pass using
SCEVPredicates would be to hold a SCEVPredicateSet and every time assumptions
need to be made a new SCEV Predicate would be created and added to the set.
Each time after calling getSCEV, the user will call the rewriteUsingPredicate
method.
We add two types of predicates
SCEVPredicateSet - implements a set of predicates
SCEVEqualPredicate - tests for equality between two SCEV expressions
We use the SCEVEqualPredicate to re-implement stride versioning. Every time we
version a stride, we will add a SCEVEqualPredicate to the context.
Instead of adding specific stride checks, LoopVectorize now adds a more
generic SCEV check.
We only need to add support for this in the LoopVectorizer since this is the
only pass that will do stride versioning.
Reviewers: mzolotukhin, anemet, hfinkel, sanjoy
Subscribers: sanjoy, hfinkel, rengolin, jmolloy, llvm-commits
Differential Revision: http://reviews.llvm.org/D13595
llvm-svn: 251800
2015-11-02 22:41:02 +08:00
|
|
|
Value *SCEVExpander::expandCodeForPredicate(const SCEVPredicate *Pred,
|
|
|
|
Instruction *IP) {
|
|
|
|
assert(IP);
|
|
|
|
switch (Pred->getKind()) {
|
|
|
|
case SCEVPredicate::P_Union:
|
|
|
|
return expandUnionPredicate(cast<SCEVUnionPredicate>(Pred), IP);
|
|
|
|
case SCEVPredicate::P_Equal:
|
|
|
|
return expandEqualPredicate(cast<SCEVEqualPredicate>(Pred), IP);
|
[SCEV][LAA] Re-commit r260085 and r260086, this time with a fix for the memory
sanitizer issue. The PredicatedScalarEvolution's copy constructor
wasn't copying the Generation value, and was leaving it un-initialized.
Original commit message:
[SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided pointer detection
Summary:
This change adds no wrap SCEV predicates with:
- support for runtime checking
- support for expression rewriting:
(sext ({x,+,y}) -> {sext(x),+,sext(y)}
(zext ({x,+,y}) -> {zext(x),+,sext(y)}
Note that we are sign extending the increment of the SCEV, even for
the zext case. This is needed to cover the fairly common case where y would
be a (small) negative integer. In order to do this, this change adds two new
flags: nusw and nssw that are applicable to AddRecExprs and permit the
transformations above.
We also change isStridedPtr in LAA to be able to make use of
these predicates. With this feature we should now always be able to
work around overflow issues in the dependence analysis.
Reviewers: mzolotukhin, sanjoy, anemet
Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel
Differential Revision: http://reviews.llvm.org/D15412
llvm-svn: 260112
2016-02-09 01:02:45 +08:00
|
|
|
case SCEVPredicate::P_Wrap: {
|
|
|
|
auto *AddRecPred = cast<SCEVWrapPredicate>(Pred);
|
|
|
|
return expandWrapPredicate(AddRecPred, IP);
|
|
|
|
}
|
[SCEV][LV] Add SCEV Predicates and use them to re-implement stride versioning
Summary:
SCEV Predicates represent conditions that typically cannot be derived from
static analysis, but can be used to reduce SCEV expressions to forms which are
usable for different optimizers.
ScalarEvolution now has the rewriteUsingPredicate method which can simplify a
SCEV expression using a SCEVPredicateSet. The normal workflow of a pass using
SCEVPredicates would be to hold a SCEVPredicateSet and every time assumptions
need to be made a new SCEV Predicate would be created and added to the set.
Each time after calling getSCEV, the user will call the rewriteUsingPredicate
method.
We add two types of predicates
SCEVPredicateSet - implements a set of predicates
SCEVEqualPredicate - tests for equality between two SCEV expressions
We use the SCEVEqualPredicate to re-implement stride versioning. Every time we
version a stride, we will add a SCEVEqualPredicate to the context.
Instead of adding specific stride checks, LoopVectorize now adds a more
generic SCEV check.
We only need to add support for this in the LoopVectorizer since this is the
only pass that will do stride versioning.
Reviewers: mzolotukhin, anemet, hfinkel, sanjoy
Subscribers: sanjoy, hfinkel, rengolin, jmolloy, llvm-commits
Differential Revision: http://reviews.llvm.org/D13595
llvm-svn: 251800
2015-11-02 22:41:02 +08:00
|
|
|
}
|
|
|
|
llvm_unreachable("Unknown SCEV predicate type");
|
|
|
|
}
|
|
|
|
|
|
|
|
Value *SCEVExpander::expandEqualPredicate(const SCEVEqualPredicate *Pred,
|
|
|
|
Instruction *IP) {
|
|
|
|
Value *Expr0 = expandCodeFor(Pred->getLHS(), Pred->getLHS()->getType(), IP);
|
|
|
|
Value *Expr1 = expandCodeFor(Pred->getRHS(), Pred->getRHS()->getType(), IP);
|
|
|
|
|
|
|
|
Builder.SetInsertPoint(IP);
|
|
|
|
auto *I = Builder.CreateICmpNE(Expr0, Expr1, "ident.check");
|
|
|
|
return I;
|
|
|
|
}
|
|
|
|
|
[SCEV][LAA] Re-commit r260085 and r260086, this time with a fix for the memory
sanitizer issue. The PredicatedScalarEvolution's copy constructor
wasn't copying the Generation value, and was leaving it un-initialized.
Original commit message:
[SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided pointer detection
Summary:
This change adds no wrap SCEV predicates with:
- support for runtime checking
- support for expression rewriting:
(sext ({x,+,y}) -> {sext(x),+,sext(y)}
(zext ({x,+,y}) -> {zext(x),+,sext(y)}
Note that we are sign extending the increment of the SCEV, even for
the zext case. This is needed to cover the fairly common case where y would
be a (small) negative integer. In order to do this, this change adds two new
flags: nusw and nssw that are applicable to AddRecExprs and permit the
transformations above.
We also change isStridedPtr in LAA to be able to make use of
these predicates. With this feature we should now always be able to
work around overflow issues in the dependence analysis.
Reviewers: mzolotukhin, sanjoy, anemet
Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel
Differential Revision: http://reviews.llvm.org/D15412
llvm-svn: 260112
2016-02-09 01:02:45 +08:00
|
|
|
Value *SCEVExpander::generateOverflowCheck(const SCEVAddRecExpr *AR,
|
|
|
|
Instruction *Loc, bool Signed) {
|
|
|
|
assert(AR->isAffine() && "Cannot generate RT check for "
|
|
|
|
"non-affine expression");
|
|
|
|
|
Re-commit [SCEV] Introduce a guarded backedge taken count and use it in LAA and LV
This re-commits r265535 which was reverted in r265541 because it
broke the windows bots. The problem was that we had a PointerIntPair
which took a pointer to a struct allocated with new. The problem
was that new doesn't provide sufficient alignment guarantees.
This pattern was already present before r265535 and it just happened
to work. To fix this, we now separate the PointerToIntPair from the
ExitNotTakenInfo struct into a pointer and a bool.
Original commit message:
Summary:
When the backedge taken codition is computed from an icmp, SCEV can
deduce the backedge taken count only if one of the sides of the icmp
is an AddRecExpr. However, due to sign/zero extensions, we sometimes
end up with something that is not an AddRecExpr.
However, we can use SCEV predicates to produce a 'guarded' expression.
This change adds a method to SCEV to get this expression, and the
SCEV predicate associated with it.
In HowManyGreaterThans and HowManyLessThans we will now add a SCEV
predicate associated with the guarded backedge taken count when the
analyzed SCEV expression is not an AddRecExpr. Note that we only do
this as an alternative to returning a 'CouldNotCompute'.
We use new feature in Loop Access Analysis and LoopVectorize to analyze
and transform more loops.
Reviewers: anemet, mzolotukhin, hfinkel, sanjoy
Subscribers: flyingforyou, mcrosier, atrick, mssimpso, sanjoy, mzolotukhin, llvm-commits
Differential Revision: http://reviews.llvm.org/D17201
llvm-svn: 265786
2016-04-08 22:29:09 +08:00
|
|
|
SCEVUnionPredicate Pred;
|
|
|
|
const SCEV *ExitCount =
|
|
|
|
SE.getPredicatedBackedgeTakenCount(AR->getLoop(), Pred);
|
2016-04-25 17:27:16 +08:00
|
|
|
|
|
|
|
assert(ExitCount != SE.getCouldNotCompute() && "Invalid loop count");
|
|
|
|
|
[SCEV][LAA] Re-commit r260085 and r260086, this time with a fix for the memory
sanitizer issue. The PredicatedScalarEvolution's copy constructor
wasn't copying the Generation value, and was leaving it un-initialized.
Original commit message:
[SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided pointer detection
Summary:
This change adds no wrap SCEV predicates with:
- support for runtime checking
- support for expression rewriting:
(sext ({x,+,y}) -> {sext(x),+,sext(y)}
(zext ({x,+,y}) -> {zext(x),+,sext(y)}
Note that we are sign extending the increment of the SCEV, even for
the zext case. This is needed to cover the fairly common case where y would
be a (small) negative integer. In order to do this, this change adds two new
flags: nusw and nssw that are applicable to AddRecExprs and permit the
transformations above.
We also change isStridedPtr in LAA to be able to make use of
these predicates. With this feature we should now always be able to
work around overflow issues in the dependence analysis.
Reviewers: mzolotukhin, sanjoy, anemet
Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel
Differential Revision: http://reviews.llvm.org/D15412
llvm-svn: 260112
2016-02-09 01:02:45 +08:00
|
|
|
const SCEV *Step = AR->getStepRecurrence(SE);
|
|
|
|
const SCEV *Start = AR->getStart();
|
|
|
|
|
|
|
|
unsigned SrcBits = SE.getTypeSizeInBits(ExitCount->getType());
|
2016-04-25 17:27:16 +08:00
|
|
|
unsigned DstBits = SE.getTypeSizeInBits(AR->getType());
|
[SCEV][LAA] Re-commit r260085 and r260086, this time with a fix for the memory
sanitizer issue. The PredicatedScalarEvolution's copy constructor
wasn't copying the Generation value, and was leaving it un-initialized.
Original commit message:
[SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided pointer detection
Summary:
This change adds no wrap SCEV predicates with:
- support for runtime checking
- support for expression rewriting:
(sext ({x,+,y}) -> {sext(x),+,sext(y)}
(zext ({x,+,y}) -> {zext(x),+,sext(y)}
Note that we are sign extending the increment of the SCEV, even for
the zext case. This is needed to cover the fairly common case where y would
be a (small) negative integer. In order to do this, this change adds two new
flags: nusw and nssw that are applicable to AddRecExprs and permit the
transformations above.
We also change isStridedPtr in LAA to be able to make use of
these predicates. With this feature we should now always be able to
work around overflow issues in the dependence analysis.
Reviewers: mzolotukhin, sanjoy, anemet
Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel
Differential Revision: http://reviews.llvm.org/D15412
llvm-svn: 260112
2016-02-09 01:02:45 +08:00
|
|
|
|
2016-04-25 17:27:16 +08:00
|
|
|
// The expression {Start,+,Step} has nusw/nssw if
|
|
|
|
// Step < 0, Start - |Step| * Backedge <= Start
|
|
|
|
// Step >= 0, Start + |Step| * Backedge > Start
|
|
|
|
// and |Step| * Backedge doesn't unsigned overflow.
|
[SCEV][LAA] Re-commit r260085 and r260086, this time with a fix for the memory
sanitizer issue. The PredicatedScalarEvolution's copy constructor
wasn't copying the Generation value, and was leaving it un-initialized.
Original commit message:
[SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided pointer detection
Summary:
This change adds no wrap SCEV predicates with:
- support for runtime checking
- support for expression rewriting:
(sext ({x,+,y}) -> {sext(x),+,sext(y)}
(zext ({x,+,y}) -> {zext(x),+,sext(y)}
Note that we are sign extending the increment of the SCEV, even for
the zext case. This is needed to cover the fairly common case where y would
be a (small) negative integer. In order to do this, this change adds two new
flags: nusw and nssw that are applicable to AddRecExprs and permit the
transformations above.
We also change isStridedPtr in LAA to be able to make use of
these predicates. With this feature we should now always be able to
work around overflow issues in the dependence analysis.
Reviewers: mzolotukhin, sanjoy, anemet
Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel
Differential Revision: http://reviews.llvm.org/D15412
llvm-svn: 260112
2016-02-09 01:02:45 +08:00
|
|
|
|
2016-04-25 17:27:16 +08:00
|
|
|
IntegerType *CountTy = IntegerType::get(Loc->getContext(), SrcBits);
|
|
|
|
Builder.SetInsertPoint(Loc);
|
|
|
|
Value *TripCountVal = expandCodeFor(ExitCount, CountTy, Loc);
|
[SCEV][LAA] Re-commit r260085 and r260086, this time with a fix for the memory
sanitizer issue. The PredicatedScalarEvolution's copy constructor
wasn't copying the Generation value, and was leaving it un-initialized.
Original commit message:
[SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided pointer detection
Summary:
This change adds no wrap SCEV predicates with:
- support for runtime checking
- support for expression rewriting:
(sext ({x,+,y}) -> {sext(x),+,sext(y)}
(zext ({x,+,y}) -> {zext(x),+,sext(y)}
Note that we are sign extending the increment of the SCEV, even for
the zext case. This is needed to cover the fairly common case where y would
be a (small) negative integer. In order to do this, this change adds two new
flags: nusw and nssw that are applicable to AddRecExprs and permit the
transformations above.
We also change isStridedPtr in LAA to be able to make use of
these predicates. With this feature we should now always be able to
work around overflow issues in the dependence analysis.
Reviewers: mzolotukhin, sanjoy, anemet
Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel
Differential Revision: http://reviews.llvm.org/D15412
llvm-svn: 260112
2016-02-09 01:02:45 +08:00
|
|
|
|
2016-04-25 17:27:16 +08:00
|
|
|
IntegerType *Ty =
|
|
|
|
IntegerType::get(Loc->getContext(), SE.getTypeSizeInBits(AR->getType()));
|
[SCEV][LAA] Re-commit r260085 and r260086, this time with a fix for the memory
sanitizer issue. The PredicatedScalarEvolution's copy constructor
wasn't copying the Generation value, and was leaving it un-initialized.
Original commit message:
[SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided pointer detection
Summary:
This change adds no wrap SCEV predicates with:
- support for runtime checking
- support for expression rewriting:
(sext ({x,+,y}) -> {sext(x),+,sext(y)}
(zext ({x,+,y}) -> {zext(x),+,sext(y)}
Note that we are sign extending the increment of the SCEV, even for
the zext case. This is needed to cover the fairly common case where y would
be a (small) negative integer. In order to do this, this change adds two new
flags: nusw and nssw that are applicable to AddRecExprs and permit the
transformations above.
We also change isStridedPtr in LAA to be able to make use of
these predicates. With this feature we should now always be able to
work around overflow issues in the dependence analysis.
Reviewers: mzolotukhin, sanjoy, anemet
Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel
Differential Revision: http://reviews.llvm.org/D15412
llvm-svn: 260112
2016-02-09 01:02:45 +08:00
|
|
|
|
2016-04-25 17:27:16 +08:00
|
|
|
Value *StepValue = expandCodeFor(Step, Ty, Loc);
|
|
|
|
Value *NegStepValue = expandCodeFor(SE.getNegativeSCEV(Step), Ty, Loc);
|
|
|
|
Value *StartValue = expandCodeFor(Start, Ty, Loc);
|
[SCEV][LAA] Re-commit r260085 and r260086, this time with a fix for the memory
sanitizer issue. The PredicatedScalarEvolution's copy constructor
wasn't copying the Generation value, and was leaving it un-initialized.
Original commit message:
[SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided pointer detection
Summary:
This change adds no wrap SCEV predicates with:
- support for runtime checking
- support for expression rewriting:
(sext ({x,+,y}) -> {sext(x),+,sext(y)}
(zext ({x,+,y}) -> {zext(x),+,sext(y)}
Note that we are sign extending the increment of the SCEV, even for
the zext case. This is needed to cover the fairly common case where y would
be a (small) negative integer. In order to do this, this change adds two new
flags: nusw and nssw that are applicable to AddRecExprs and permit the
transformations above.
We also change isStridedPtr in LAA to be able to make use of
these predicates. With this feature we should now always be able to
work around overflow issues in the dependence analysis.
Reviewers: mzolotukhin, sanjoy, anemet
Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel
Differential Revision: http://reviews.llvm.org/D15412
llvm-svn: 260112
2016-02-09 01:02:45 +08:00
|
|
|
|
2016-04-25 17:27:16 +08:00
|
|
|
ConstantInt *Zero =
|
|
|
|
ConstantInt::get(Loc->getContext(), APInt::getNullValue(DstBits));
|
[SCEV][LAA] Re-commit r260085 and r260086, this time with a fix for the memory
sanitizer issue. The PredicatedScalarEvolution's copy constructor
wasn't copying the Generation value, and was leaving it un-initialized.
Original commit message:
[SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided pointer detection
Summary:
This change adds no wrap SCEV predicates with:
- support for runtime checking
- support for expression rewriting:
(sext ({x,+,y}) -> {sext(x),+,sext(y)}
(zext ({x,+,y}) -> {zext(x),+,sext(y)}
Note that we are sign extending the increment of the SCEV, even for
the zext case. This is needed to cover the fairly common case where y would
be a (small) negative integer. In order to do this, this change adds two new
flags: nusw and nssw that are applicable to AddRecExprs and permit the
transformations above.
We also change isStridedPtr in LAA to be able to make use of
these predicates. With this feature we should now always be able to
work around overflow issues in the dependence analysis.
Reviewers: mzolotukhin, sanjoy, anemet
Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel
Differential Revision: http://reviews.llvm.org/D15412
llvm-svn: 260112
2016-02-09 01:02:45 +08:00
|
|
|
|
|
|
|
Builder.SetInsertPoint(Loc);
|
2016-04-25 17:27:16 +08:00
|
|
|
// Compute |Step|
|
|
|
|
Value *StepCompare = Builder.CreateICmp(ICmpInst::ICMP_SLT, StepValue, Zero);
|
|
|
|
Value *AbsStep = Builder.CreateSelect(StepCompare, NegStepValue, StepValue);
|
|
|
|
|
|
|
|
// Get the backedge taken count and truncate or extended to the AR type.
|
|
|
|
Value *TruncTripCount = Builder.CreateZExtOrTrunc(TripCountVal, Ty);
|
|
|
|
auto *MulF = Intrinsic::getDeclaration(Loc->getModule(),
|
|
|
|
Intrinsic::umul_with_overflow, Ty);
|
|
|
|
|
|
|
|
// Compute |Step| * Backedge
|
|
|
|
CallInst *Mul = Builder.CreateCall(MulF, {AbsStep, TruncTripCount}, "mul");
|
|
|
|
Value *MulV = Builder.CreateExtractValue(Mul, 0, "mul.result");
|
|
|
|
Value *OfMul = Builder.CreateExtractValue(Mul, 1, "mul.overflow");
|
|
|
|
|
|
|
|
// Compute:
|
|
|
|
// Start + |Step| * Backedge < Start
|
|
|
|
// Start - |Step| * Backedge > Start
|
|
|
|
Value *Add = Builder.CreateAdd(StartValue, MulV);
|
|
|
|
Value *Sub = Builder.CreateSub(StartValue, MulV);
|
|
|
|
|
|
|
|
Value *EndCompareGT = Builder.CreateICmp(
|
|
|
|
Signed ? ICmpInst::ICMP_SGT : ICmpInst::ICMP_UGT, Sub, StartValue);
|
|
|
|
|
|
|
|
Value *EndCompareLT = Builder.CreateICmp(
|
|
|
|
Signed ? ICmpInst::ICMP_SLT : ICmpInst::ICMP_ULT, Add, StartValue);
|
|
|
|
|
|
|
|
// Select the answer based on the sign of Step.
|
|
|
|
Value *EndCheck =
|
|
|
|
Builder.CreateSelect(StepCompare, EndCompareGT, EndCompareLT);
|
|
|
|
|
|
|
|
// If the backedge taken count type is larger than the AR type,
|
|
|
|
// check that we don't drop any bits by truncating it. If we are
|
|
|
|
// droping bits, then we have overflow (unless the step is zero).
|
|
|
|
if (SE.getTypeSizeInBits(CountTy) > SE.getTypeSizeInBits(Ty)) {
|
|
|
|
auto MaxVal = APInt::getMaxValue(DstBits).zext(SrcBits);
|
|
|
|
auto *BackedgeCheck =
|
|
|
|
Builder.CreateICmp(ICmpInst::ICMP_UGT, TripCountVal,
|
|
|
|
ConstantInt::get(Loc->getContext(), MaxVal));
|
|
|
|
BackedgeCheck = Builder.CreateAnd(
|
|
|
|
BackedgeCheck, Builder.CreateICmp(ICmpInst::ICMP_NE, StepValue, Zero));
|
|
|
|
|
|
|
|
EndCheck = Builder.CreateOr(EndCheck, BackedgeCheck);
|
|
|
|
}
|
[SCEV][LAA] Re-commit r260085 and r260086, this time with a fix for the memory
sanitizer issue. The PredicatedScalarEvolution's copy constructor
wasn't copying the Generation value, and was leaving it un-initialized.
Original commit message:
[SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided pointer detection
Summary:
This change adds no wrap SCEV predicates with:
- support for runtime checking
- support for expression rewriting:
(sext ({x,+,y}) -> {sext(x),+,sext(y)}
(zext ({x,+,y}) -> {zext(x),+,sext(y)}
Note that we are sign extending the increment of the SCEV, even for
the zext case. This is needed to cover the fairly common case where y would
be a (small) negative integer. In order to do this, this change adds two new
flags: nusw and nssw that are applicable to AddRecExprs and permit the
transformations above.
We also change isStridedPtr in LAA to be able to make use of
these predicates. With this feature we should now always be able to
work around overflow issues in the dependence analysis.
Reviewers: mzolotukhin, sanjoy, anemet
Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel
Differential Revision: http://reviews.llvm.org/D15412
llvm-svn: 260112
2016-02-09 01:02:45 +08:00
|
|
|
|
2016-04-25 17:27:16 +08:00
|
|
|
EndCheck = Builder.CreateOr(EndCheck, OfMul);
|
|
|
|
return EndCheck;
|
[SCEV][LAA] Re-commit r260085 and r260086, this time with a fix for the memory
sanitizer issue. The PredicatedScalarEvolution's copy constructor
wasn't copying the Generation value, and was leaving it un-initialized.
Original commit message:
[SCEV][LAA] Add no wrap SCEV predicates and use use them to improve strided pointer detection
Summary:
This change adds no wrap SCEV predicates with:
- support for runtime checking
- support for expression rewriting:
(sext ({x,+,y}) -> {sext(x),+,sext(y)}
(zext ({x,+,y}) -> {zext(x),+,sext(y)}
Note that we are sign extending the increment of the SCEV, even for
the zext case. This is needed to cover the fairly common case where y would
be a (small) negative integer. In order to do this, this change adds two new
flags: nusw and nssw that are applicable to AddRecExprs and permit the
transformations above.
We also change isStridedPtr in LAA to be able to make use of
these predicates. With this feature we should now always be able to
work around overflow issues in the dependence analysis.
Reviewers: mzolotukhin, sanjoy, anemet
Subscribers: mzolotukhin, sanjoy, llvm-commits, rengolin, jmolloy, hfinkel
Differential Revision: http://reviews.llvm.org/D15412
llvm-svn: 260112
2016-02-09 01:02:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
Value *SCEVExpander::expandWrapPredicate(const SCEVWrapPredicate *Pred,
|
|
|
|
Instruction *IP) {
|
|
|
|
const auto *A = cast<SCEVAddRecExpr>(Pred->getExpr());
|
|
|
|
Value *NSSWCheck = nullptr, *NUSWCheck = nullptr;
|
|
|
|
|
|
|
|
// Add a check for NUSW
|
|
|
|
if (Pred->getFlags() & SCEVWrapPredicate::IncrementNUSW)
|
|
|
|
NUSWCheck = generateOverflowCheck(A, IP, false);
|
|
|
|
|
|
|
|
// Add a check for NSSW
|
|
|
|
if (Pred->getFlags() & SCEVWrapPredicate::IncrementNSSW)
|
|
|
|
NSSWCheck = generateOverflowCheck(A, IP, true);
|
|
|
|
|
|
|
|
if (NUSWCheck && NSSWCheck)
|
|
|
|
return Builder.CreateOr(NUSWCheck, NSSWCheck);
|
|
|
|
|
|
|
|
if (NUSWCheck)
|
|
|
|
return NUSWCheck;
|
|
|
|
|
|
|
|
if (NSSWCheck)
|
|
|
|
return NSSWCheck;
|
|
|
|
|
|
|
|
return ConstantInt::getFalse(IP->getContext());
|
|
|
|
}
|
|
|
|
|
[SCEV][LV] Add SCEV Predicates and use them to re-implement stride versioning
Summary:
SCEV Predicates represent conditions that typically cannot be derived from
static analysis, but can be used to reduce SCEV expressions to forms which are
usable for different optimizers.
ScalarEvolution now has the rewriteUsingPredicate method which can simplify a
SCEV expression using a SCEVPredicateSet. The normal workflow of a pass using
SCEVPredicates would be to hold a SCEVPredicateSet and every time assumptions
need to be made a new SCEV Predicate would be created and added to the set.
Each time after calling getSCEV, the user will call the rewriteUsingPredicate
method.
We add two types of predicates
SCEVPredicateSet - implements a set of predicates
SCEVEqualPredicate - tests for equality between two SCEV expressions
We use the SCEVEqualPredicate to re-implement stride versioning. Every time we
version a stride, we will add a SCEVEqualPredicate to the context.
Instead of adding specific stride checks, LoopVectorize now adds a more
generic SCEV check.
We only need to add support for this in the LoopVectorizer since this is the
only pass that will do stride versioning.
Reviewers: mzolotukhin, anemet, hfinkel, sanjoy
Subscribers: sanjoy, hfinkel, rengolin, jmolloy, llvm-commits
Differential Revision: http://reviews.llvm.org/D13595
llvm-svn: 251800
2015-11-02 22:41:02 +08:00
|
|
|
Value *SCEVExpander::expandUnionPredicate(const SCEVUnionPredicate *Union,
|
|
|
|
Instruction *IP) {
|
|
|
|
auto *BoolType = IntegerType::get(IP->getContext(), 1);
|
|
|
|
Value *Check = ConstantInt::getNullValue(BoolType);
|
|
|
|
|
|
|
|
// Loop over all checks in this set.
|
|
|
|
for (auto Pred : Union->getPredicates()) {
|
|
|
|
auto *NextCheck = expandCodeForPredicate(Pred, IP);
|
|
|
|
Builder.SetInsertPoint(IP);
|
|
|
|
Check = Builder.CreateOr(Check, NextCheck);
|
|
|
|
}
|
|
|
|
|
|
|
|
return Check;
|
|
|
|
}
|
|
|
|
|
2012-07-14 07:33:10 +08:00
|
|
|
namespace {
|
|
|
|
// Search for a SCEV subexpression that is not safe to expand. Any expression
|
|
|
|
// that may expand to a !isSafeToSpeculativelyExecute value is unsafe, namely
|
|
|
|
// UDiv expressions. We don't know if the UDiv is derived from an IR divide
|
|
|
|
// instruction, but the important thing is that we prove the denominator is
|
|
|
|
// nonzero before expansion.
|
|
|
|
//
|
|
|
|
// IVUsers already checks that IV-derived expressions are safe. So this check is
|
|
|
|
// only needed when the expression includes some subexpression that is not IV
|
|
|
|
// derived.
|
|
|
|
//
|
|
|
|
// Currently, we only allow division by a nonzero constant here. If this is
|
|
|
|
// inadequate, we could easily allow division by SCEVUnknown by using
|
|
|
|
// ValueTracking to check isKnownNonZero().
|
2013-10-26 05:35:56 +08:00
|
|
|
//
|
|
|
|
// We cannot generally expand recurrences unless the step dominates the loop
|
|
|
|
// header. The expander handles the special case of affine recurrences by
|
|
|
|
// scaling the recurrence outside the loop, but this technique isn't generally
|
|
|
|
// applicable. Expanding a nested recurrence outside a loop requires computing
|
|
|
|
// binomial coefficients. This could be done, but the recurrence has to be in a
|
|
|
|
// perfectly reduced form, which can't be guaranteed.
|
2012-07-14 07:33:10 +08:00
|
|
|
struct SCEVFindUnsafe {
|
2013-10-26 05:35:56 +08:00
|
|
|
ScalarEvolution &SE;
|
2012-07-14 07:33:10 +08:00
|
|
|
bool IsUnsafe;
|
|
|
|
|
2013-10-26 05:35:56 +08:00
|
|
|
SCEVFindUnsafe(ScalarEvolution &se): SE(se), IsUnsafe(false) {}
|
2012-07-14 07:33:10 +08:00
|
|
|
|
|
|
|
bool follow(const SCEV *S) {
|
2013-10-26 05:35:56 +08:00
|
|
|
if (const SCEVUDivExpr *D = dyn_cast<SCEVUDivExpr>(S)) {
|
|
|
|
const SCEVConstant *SC = dyn_cast<SCEVConstant>(D->getRHS());
|
|
|
|
if (!SC || SC->getValue()->isZero()) {
|
|
|
|
IsUnsafe = true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (const SCEVAddRecExpr *AR = dyn_cast<SCEVAddRecExpr>(S)) {
|
|
|
|
const SCEV *Step = AR->getStepRecurrence(SE);
|
|
|
|
if (!AR->isAffine() && !SE.dominates(Step, AR->getLoop()->getHeader())) {
|
|
|
|
IsUnsafe = true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
2012-07-14 07:33:10 +08:00
|
|
|
}
|
|
|
|
bool isDone() const { return IsUnsafe; }
|
|
|
|
};
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2012-07-14 07:33:10 +08:00
|
|
|
|
|
|
|
namespace llvm {
|
2013-10-26 05:35:56 +08:00
|
|
|
bool isSafeToExpand(const SCEV *S, ScalarEvolution &SE) {
|
|
|
|
SCEVFindUnsafe Search(SE);
|
2012-07-14 07:33:10 +08:00
|
|
|
visitAll(S, Search);
|
|
|
|
return !Search.IsUnsafe;
|
|
|
|
}
|
|
|
|
}
|