2014-08-22 05:50:01 +08:00
|
|
|
//===-- AtomicExpandPass.cpp - Expand atomic instructions -------===//
|
2014-04-03 19:44:58 +08:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file contains a pass (at IR level) to replace atomic instructions with
|
2015-12-16 08:49:36 +08:00
|
|
|
// target specific instruction which implement the same semantics in a way
|
|
|
|
// which better fits the target backend. This can include the use of either
|
|
|
|
// (intrinsic-based) load-linked/store-conditional loops, AtomicCmpXchg, or
|
|
|
|
// type coercions.
|
2014-04-03 19:44:58 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2015-08-03 23:29:47 +08:00
|
|
|
#include "llvm/CodeGen/AtomicExpandUtils.h"
|
2014-04-03 19:44:58 +08:00
|
|
|
#include "llvm/CodeGen/Passes.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
|
|
|
#include "llvm/IR/IRBuilder.h"
|
2014-09-04 05:29:59 +08:00
|
|
|
#include "llvm/IR/InstIterator.h"
|
2014-04-03 19:44:58 +08:00
|
|
|
#include "llvm/IR/Instructions.h"
|
|
|
|
#include "llvm/IR/Intrinsics.h"
|
|
|
|
#include "llvm/IR/Module.h"
|
|
|
|
#include "llvm/Support/Debug.h"
|
2015-12-16 09:24:05 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2014-04-03 19:44:58 +08:00
|
|
|
#include "llvm/Target/TargetLowering.h"
|
|
|
|
#include "llvm/Target/TargetMachine.h"
|
2014-06-20 05:03:04 +08:00
|
|
|
#include "llvm/Target/TargetSubtargetInfo.h"
|
|
|
|
|
2014-04-03 19:44:58 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2014-08-22 05:50:01 +08:00
|
|
|
#define DEBUG_TYPE "atomic-expand"
|
2014-04-22 10:02:50 +08:00
|
|
|
|
2014-04-03 19:44:58 +08:00
|
|
|
namespace {
|
2014-08-22 05:50:01 +08:00
|
|
|
class AtomicExpand: public FunctionPass {
|
2014-06-20 05:03:04 +08:00
|
|
|
const TargetMachine *TM;
|
2015-01-27 03:45:40 +08:00
|
|
|
const TargetLowering *TLI;
|
2014-04-03 19:44:58 +08:00
|
|
|
public:
|
|
|
|
static char ID; // Pass identification, replacement for typeid
|
2014-08-22 05:50:01 +08:00
|
|
|
explicit AtomicExpand(const TargetMachine *TM = nullptr)
|
2015-01-27 03:45:40 +08:00
|
|
|
: FunctionPass(ID), TM(TM), TLI(nullptr) {
|
2014-08-22 05:50:01 +08:00
|
|
|
initializeAtomicExpandPass(*PassRegistry::getPassRegistry());
|
2014-04-18 02:22:47 +08:00
|
|
|
}
|
2014-04-03 19:44:58 +08:00
|
|
|
|
|
|
|
bool runOnFunction(Function &F) override;
|
|
|
|
|
2014-09-04 05:29:59 +08:00
|
|
|
private:
|
Add AtomicExpandPass::bracketInstWithFences, and use it whenever getInsertFencesForAtomic would trigger in SelectionDAGBuilder
Summary:
The goal is to eventually remove all the code related to getInsertFencesForAtomic
in SelectionDAGBuilder as it is wrong (designed for ARM, not really portable, works
mostly by accident because the backends are overly conservative), and repeats the
same logic that goes in emitLeading/TrailingFence.
In this patch, I make AtomicExpandPass insert the fences as it knows better
where to put them. Because this requires getting the fences and not just
passing an IRBuilder around, I had to change the return type of
emitLeading/TrailingFence.
This code only triggers on ARM for now. Because it is earlier in the pipeline
than SelectionDAGBuilder, it triggers and lowers atomic accesses to atomic so
SelectionDAGBuilder does not add barriers anymore on ARM.
If this patch is accepted I plan to implement emitLeading/TrailingFence for all
backends that setInsertFencesForAtomic(true), which will allow both making them
less conservative and simplifying SelectionDAGBuilder once they are all using
this interface.
This should not cause any functionnal change so the existing tests are used
and not modified.
Test Plan: make check-all, benefits from existing tests of atomics on ARM
Reviewers: jfb, t.p.northover
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D5179
llvm-svn: 218329
2014-09-24 04:31:14 +08:00
|
|
|
bool bracketInstWithFences(Instruction *I, AtomicOrdering Order,
|
|
|
|
bool IsStore, bool IsLoad);
|
2015-12-16 08:49:36 +08:00
|
|
|
IntegerType *getCorrespondingIntegerType(Type *T, const DataLayout &DL);
|
|
|
|
LoadInst *convertAtomicLoadToIntegerType(LoadInst *LI);
|
2015-09-12 01:08:28 +08:00
|
|
|
bool tryExpandAtomicLoad(LoadInst *LI);
|
2014-09-24 04:59:25 +08:00
|
|
|
bool expandAtomicLoadToLL(LoadInst *LI);
|
|
|
|
bool expandAtomicLoadToCmpXchg(LoadInst *LI);
|
2015-12-16 08:49:36 +08:00
|
|
|
StoreInst *convertAtomicStoreToIntegerType(StoreInst *SI);
|
2014-09-04 05:29:59 +08:00
|
|
|
bool expandAtomicStore(StoreInst *SI);
|
Mutate TargetLowering::shouldExpandAtomicRMWInIR to specifically dictate how AtomicRMWInsts are expanded.
Summary:
In PNaCl, most atomic instructions have their own @llvm.nacl.atomic.* function, each one, with a few exceptions, represents a consistent behaviour across all NaCl-supported targets. Unfortunately, the atomic RMW operations nand, [u]min, and [u]max aren't directly represented by any such @llvm.nacl.atomic.* function. This patch refines shouldExpandAtomicRMWInIR in TargetLowering so that a future `Le32TargetLowering` class can selectively inform the caller how the target desires the atomic RMW instruction to be expanded (ie via load-linked/store-conditional for ARM/AArch64, via cmpxchg for X86/others?, or not at all for Mips) if at all.
This does not represent a behavioural change and as such no tests were added.
Patch by: Richard Diamond.
Reviewers: jfb
Reviewed By: jfb
Subscribers: jfb, aemerson, t.p.northover, llvm-commits
Differential Revision: http://reviews.llvm.org/D7713
llvm-svn: 231250
2015-03-04 23:47:57 +08:00
|
|
|
bool tryExpandAtomicRMW(AtomicRMWInst *AI);
|
2015-12-03 02:12:57 +08:00
|
|
|
bool expandAtomicOpToLLSC(
|
|
|
|
Instruction *I, Value *Addr, AtomicOrdering MemOpOrder,
|
|
|
|
std::function<Value *(IRBuilder<> &, Value *)> PerformOp);
|
2016-02-19 08:06:41 +08:00
|
|
|
AtomicCmpXchgInst *convertCmpXchgToIntegerType(AtomicCmpXchgInst *CI);
|
2014-04-03 19:44:58 +08:00
|
|
|
bool expandAtomicCmpXchg(AtomicCmpXchgInst *CI);
|
2014-09-26 01:27:43 +08:00
|
|
|
bool isIdempotentRMW(AtomicRMWInst *AI);
|
|
|
|
bool simplifyIdempotentRMW(AtomicRMWInst *AI);
|
2014-04-18 02:22:47 +08:00
|
|
|
};
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2014-04-03 19:44:58 +08:00
|
|
|
|
2014-08-22 05:50:01 +08:00
|
|
|
char AtomicExpand::ID = 0;
|
|
|
|
char &llvm::AtomicExpandID = AtomicExpand::ID;
|
|
|
|
INITIALIZE_TM_PASS(AtomicExpand, "atomic-expand",
|
|
|
|
"Expand Atomic calls in terms of either load-linked & store-conditional or cmpxchg",
|
2014-06-11 15:04:37 +08:00
|
|
|
false, false)
|
2014-04-03 19:44:58 +08:00
|
|
|
|
2014-08-22 05:50:01 +08:00
|
|
|
FunctionPass *llvm::createAtomicExpandPass(const TargetMachine *TM) {
|
|
|
|
return new AtomicExpand(TM);
|
2014-04-03 19:44:58 +08:00
|
|
|
}
|
|
|
|
|
2014-08-22 05:50:01 +08:00
|
|
|
bool AtomicExpand::runOnFunction(Function &F) {
|
2015-01-27 09:04:42 +08:00
|
|
|
if (!TM || !TM->getSubtargetImpl(F)->enableAtomicExpand())
|
2014-04-18 02:22:47 +08:00
|
|
|
return false;
|
2015-01-27 09:04:42 +08:00
|
|
|
TLI = TM->getSubtargetImpl(F)->getTargetLowering();
|
2014-04-18 02:22:47 +08:00
|
|
|
|
2014-04-03 19:44:58 +08:00
|
|
|
SmallVector<Instruction *, 1> AtomicInsts;
|
|
|
|
|
|
|
|
// Changing control-flow while iterating through it is a bad idea, so gather a
|
|
|
|
// list of all atomic instructions before we start.
|
2014-09-04 05:29:59 +08:00
|
|
|
for (inst_iterator I = inst_begin(F), E = inst_end(F); I != E; ++I) {
|
|
|
|
if (I->isAtomic())
|
|
|
|
AtomicInsts.push_back(&*I);
|
|
|
|
}
|
2014-04-03 19:44:58 +08:00
|
|
|
|
|
|
|
bool MadeChange = false;
|
2014-09-04 05:29:59 +08:00
|
|
|
for (auto I : AtomicInsts) {
|
|
|
|
auto LI = dyn_cast<LoadInst>(I);
|
|
|
|
auto SI = dyn_cast<StoreInst>(I);
|
|
|
|
auto RMWI = dyn_cast<AtomicRMWInst>(I);
|
|
|
|
auto CASI = dyn_cast<AtomicCmpXchgInst>(I);
|
|
|
|
assert((LI || SI || RMWI || CASI || isa<FenceInst>(I)) &&
|
|
|
|
"Unknown atomic instruction");
|
|
|
|
|
2015-01-27 03:45:40 +08:00
|
|
|
if (TLI->getInsertFencesForAtomic()) {
|
2016-02-19 03:45:31 +08:00
|
|
|
auto FenceOrdering = Monotonic;
|
|
|
|
bool IsStore, IsLoad;
|
Add AtomicExpandPass::bracketInstWithFences, and use it whenever getInsertFencesForAtomic would trigger in SelectionDAGBuilder
Summary:
The goal is to eventually remove all the code related to getInsertFencesForAtomic
in SelectionDAGBuilder as it is wrong (designed for ARM, not really portable, works
mostly by accident because the backends are overly conservative), and repeats the
same logic that goes in emitLeading/TrailingFence.
In this patch, I make AtomicExpandPass insert the fences as it knows better
where to put them. Because this requires getting the fences and not just
passing an IRBuilder around, I had to change the return type of
emitLeading/TrailingFence.
This code only triggers on ARM for now. Because it is earlier in the pipeline
than SelectionDAGBuilder, it triggers and lowers atomic accesses to atomic so
SelectionDAGBuilder does not add barriers anymore on ARM.
If this patch is accepted I plan to implement emitLeading/TrailingFence for all
backends that setInsertFencesForAtomic(true), which will allow both making them
less conservative and simplifying SelectionDAGBuilder once they are all using
this interface.
This should not cause any functionnal change so the existing tests are used
and not modified.
Test Plan: make check-all, benefits from existing tests of atomics on ARM
Reviewers: jfb, t.p.northover
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D5179
llvm-svn: 218329
2014-09-24 04:31:14 +08:00
|
|
|
if (LI && isAtLeastAcquire(LI->getOrdering())) {
|
|
|
|
FenceOrdering = LI->getOrdering();
|
|
|
|
LI->setOrdering(Monotonic);
|
|
|
|
IsStore = false;
|
|
|
|
IsLoad = true;
|
|
|
|
} else if (SI && isAtLeastRelease(SI->getOrdering())) {
|
|
|
|
FenceOrdering = SI->getOrdering();
|
|
|
|
SI->setOrdering(Monotonic);
|
|
|
|
IsStore = true;
|
|
|
|
IsLoad = false;
|
|
|
|
} else if (RMWI && (isAtLeastRelease(RMWI->getOrdering()) ||
|
|
|
|
isAtLeastAcquire(RMWI->getOrdering()))) {
|
|
|
|
FenceOrdering = RMWI->getOrdering();
|
|
|
|
RMWI->setOrdering(Monotonic);
|
|
|
|
IsStore = IsLoad = true;
|
2015-09-12 01:08:28 +08:00
|
|
|
} else if (CASI && !TLI->shouldExpandAtomicCmpXchgInIR(CASI) &&
|
2015-01-27 03:45:40 +08:00
|
|
|
(isAtLeastRelease(CASI->getSuccessOrdering()) ||
|
|
|
|
isAtLeastAcquire(CASI->getSuccessOrdering()))) {
|
Add AtomicExpandPass::bracketInstWithFences, and use it whenever getInsertFencesForAtomic would trigger in SelectionDAGBuilder
Summary:
The goal is to eventually remove all the code related to getInsertFencesForAtomic
in SelectionDAGBuilder as it is wrong (designed for ARM, not really portable, works
mostly by accident because the backends are overly conservative), and repeats the
same logic that goes in emitLeading/TrailingFence.
In this patch, I make AtomicExpandPass insert the fences as it knows better
where to put them. Because this requires getting the fences and not just
passing an IRBuilder around, I had to change the return type of
emitLeading/TrailingFence.
This code only triggers on ARM for now. Because it is earlier in the pipeline
than SelectionDAGBuilder, it triggers and lowers atomic accesses to atomic so
SelectionDAGBuilder does not add barriers anymore on ARM.
If this patch is accepted I plan to implement emitLeading/TrailingFence for all
backends that setInsertFencesForAtomic(true), which will allow both making them
less conservative and simplifying SelectionDAGBuilder once they are all using
this interface.
This should not cause any functionnal change so the existing tests are used
and not modified.
Test Plan: make check-all, benefits from existing tests of atomics on ARM
Reviewers: jfb, t.p.northover
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D5179
llvm-svn: 218329
2014-09-24 04:31:14 +08:00
|
|
|
// If a compare and swap is lowered to LL/SC, we can do smarter fence
|
|
|
|
// insertion, with a stronger one on the success path than on the
|
|
|
|
// failure path. As a result, fence insertion is directly done by
|
|
|
|
// expandAtomicCmpXchg in that case.
|
|
|
|
FenceOrdering = CASI->getSuccessOrdering();
|
|
|
|
CASI->setSuccessOrdering(Monotonic);
|
|
|
|
CASI->setFailureOrdering(Monotonic);
|
|
|
|
IsStore = IsLoad = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (FenceOrdering != Monotonic) {
|
|
|
|
MadeChange |= bracketInstWithFences(I, FenceOrdering, IsStore, IsLoad);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-09-12 01:08:28 +08:00
|
|
|
if (LI) {
|
2015-12-16 08:49:36 +08:00
|
|
|
if (LI->getType()->isFloatingPointTy()) {
|
|
|
|
// TODO: add a TLI hook to control this so that each target can
|
|
|
|
// convert to lowering the original type one at a time.
|
|
|
|
LI = convertAtomicLoadToIntegerType(LI);
|
|
|
|
assert(LI->getType()->isIntegerTy() && "invariant broken");
|
|
|
|
MadeChange = true;
|
|
|
|
}
|
|
|
|
|
2015-09-12 01:08:28 +08:00
|
|
|
MadeChange |= tryExpandAtomicLoad(LI);
|
2015-12-16 08:49:36 +08:00
|
|
|
} else if (SI) {
|
|
|
|
if (SI->getValueOperand()->getType()->isFloatingPointTy()) {
|
|
|
|
// TODO: add a TLI hook to control this so that each target can
|
|
|
|
// convert to lowering the original type one at a time.
|
|
|
|
SI = convertAtomicStoreToIntegerType(SI);
|
|
|
|
assert(SI->getValueOperand()->getType()->isIntegerTy() &&
|
|
|
|
"invariant broken");
|
|
|
|
MadeChange = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (TLI->shouldExpandAtomicStoreInIR(SI))
|
|
|
|
MadeChange |= expandAtomicStore(SI);
|
2014-09-26 01:27:43 +08:00
|
|
|
} else if (RMWI) {
|
|
|
|
// There are two different ways of expanding RMW instructions:
|
|
|
|
// - into a load if it is idempotent
|
|
|
|
// - into a Cmpxchg/LL-SC loop otherwise
|
|
|
|
// we try them in that order.
|
Mutate TargetLowering::shouldExpandAtomicRMWInIR to specifically dictate how AtomicRMWInsts are expanded.
Summary:
In PNaCl, most atomic instructions have their own @llvm.nacl.atomic.* function, each one, with a few exceptions, represents a consistent behaviour across all NaCl-supported targets. Unfortunately, the atomic RMW operations nand, [u]min, and [u]max aren't directly represented by any such @llvm.nacl.atomic.* function. This patch refines shouldExpandAtomicRMWInIR in TargetLowering so that a future `Le32TargetLowering` class can selectively inform the caller how the target desires the atomic RMW instruction to be expanded (ie via load-linked/store-conditional for ARM/AArch64, via cmpxchg for X86/others?, or not at all for Mips) if at all.
This does not represent a behavioural change and as such no tests were added.
Patch by: Richard Diamond.
Reviewers: jfb
Reviewed By: jfb
Subscribers: jfb, aemerson, t.p.northover, llvm-commits
Differential Revision: http://reviews.llvm.org/D7713
llvm-svn: 231250
2015-03-04 23:47:57 +08:00
|
|
|
|
|
|
|
if (isIdempotentRMW(RMWI) && simplifyIdempotentRMW(RMWI)) {
|
|
|
|
MadeChange = true;
|
|
|
|
} else {
|
|
|
|
MadeChange |= tryExpandAtomicRMW(RMWI);
|
|
|
|
}
|
2016-02-19 08:06:41 +08:00
|
|
|
} else if (CASI) {
|
|
|
|
// TODO: when we're ready to make the change at the IR level, we can
|
|
|
|
// extend convertCmpXchgToInteger for floating point too.
|
|
|
|
assert(!CASI->getCompareOperand()->getType()->isFloatingPointTy() &&
|
|
|
|
"unimplemented - floating point not legal at IR level");
|
|
|
|
if (CASI->getCompareOperand()->getType()->isPointerTy() ) {
|
|
|
|
// TODO: add a TLI hook to control this so that each target can
|
|
|
|
// convert to lowering the original type one at a time.
|
|
|
|
CASI = convertCmpXchgToIntegerType(CASI);
|
|
|
|
assert(CASI->getCompareOperand()->getType()->isIntegerTy() &&
|
|
|
|
"invariant broken");
|
|
|
|
MadeChange = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (TLI->shouldExpandAtomicCmpXchgInIR(CASI))
|
|
|
|
MadeChange |= expandAtomicCmpXchg(CASI);
|
2014-09-04 05:29:59 +08:00
|
|
|
}
|
2014-04-03 19:44:58 +08:00
|
|
|
}
|
|
|
|
return MadeChange;
|
|
|
|
}
|
|
|
|
|
Add AtomicExpandPass::bracketInstWithFences, and use it whenever getInsertFencesForAtomic would trigger in SelectionDAGBuilder
Summary:
The goal is to eventually remove all the code related to getInsertFencesForAtomic
in SelectionDAGBuilder as it is wrong (designed for ARM, not really portable, works
mostly by accident because the backends are overly conservative), and repeats the
same logic that goes in emitLeading/TrailingFence.
In this patch, I make AtomicExpandPass insert the fences as it knows better
where to put them. Because this requires getting the fences and not just
passing an IRBuilder around, I had to change the return type of
emitLeading/TrailingFence.
This code only triggers on ARM for now. Because it is earlier in the pipeline
than SelectionDAGBuilder, it triggers and lowers atomic accesses to atomic so
SelectionDAGBuilder does not add barriers anymore on ARM.
If this patch is accepted I plan to implement emitLeading/TrailingFence for all
backends that setInsertFencesForAtomic(true), which will allow both making them
less conservative and simplifying SelectionDAGBuilder once they are all using
this interface.
This should not cause any functionnal change so the existing tests are used
and not modified.
Test Plan: make check-all, benefits from existing tests of atomics on ARM
Reviewers: jfb, t.p.northover
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D5179
llvm-svn: 218329
2014-09-24 04:31:14 +08:00
|
|
|
bool AtomicExpand::bracketInstWithFences(Instruction *I, AtomicOrdering Order,
|
|
|
|
bool IsStore, bool IsLoad) {
|
|
|
|
IRBuilder<> Builder(I);
|
|
|
|
|
2015-01-27 03:45:40 +08:00
|
|
|
auto LeadingFence = TLI->emitLeadingFence(Builder, Order, IsStore, IsLoad);
|
Add AtomicExpandPass::bracketInstWithFences, and use it whenever getInsertFencesForAtomic would trigger in SelectionDAGBuilder
Summary:
The goal is to eventually remove all the code related to getInsertFencesForAtomic
in SelectionDAGBuilder as it is wrong (designed for ARM, not really portable, works
mostly by accident because the backends are overly conservative), and repeats the
same logic that goes in emitLeading/TrailingFence.
In this patch, I make AtomicExpandPass insert the fences as it knows better
where to put them. Because this requires getting the fences and not just
passing an IRBuilder around, I had to change the return type of
emitLeading/TrailingFence.
This code only triggers on ARM for now. Because it is earlier in the pipeline
than SelectionDAGBuilder, it triggers and lowers atomic accesses to atomic so
SelectionDAGBuilder does not add barriers anymore on ARM.
If this patch is accepted I plan to implement emitLeading/TrailingFence for all
backends that setInsertFencesForAtomic(true), which will allow both making them
less conservative and simplifying SelectionDAGBuilder once they are all using
this interface.
This should not cause any functionnal change so the existing tests are used
and not modified.
Test Plan: make check-all, benefits from existing tests of atomics on ARM
Reviewers: jfb, t.p.northover
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D5179
llvm-svn: 218329
2014-09-24 04:31:14 +08:00
|
|
|
|
2015-01-27 03:45:40 +08:00
|
|
|
auto TrailingFence = TLI->emitTrailingFence(Builder, Order, IsStore, IsLoad);
|
Add AtomicExpandPass::bracketInstWithFences, and use it whenever getInsertFencesForAtomic would trigger in SelectionDAGBuilder
Summary:
The goal is to eventually remove all the code related to getInsertFencesForAtomic
in SelectionDAGBuilder as it is wrong (designed for ARM, not really portable, works
mostly by accident because the backends are overly conservative), and repeats the
same logic that goes in emitLeading/TrailingFence.
In this patch, I make AtomicExpandPass insert the fences as it knows better
where to put them. Because this requires getting the fences and not just
passing an IRBuilder around, I had to change the return type of
emitLeading/TrailingFence.
This code only triggers on ARM for now. Because it is earlier in the pipeline
than SelectionDAGBuilder, it triggers and lowers atomic accesses to atomic so
SelectionDAGBuilder does not add barriers anymore on ARM.
If this patch is accepted I plan to implement emitLeading/TrailingFence for all
backends that setInsertFencesForAtomic(true), which will allow both making them
less conservative and simplifying SelectionDAGBuilder once they are all using
this interface.
This should not cause any functionnal change so the existing tests are used
and not modified.
Test Plan: make check-all, benefits from existing tests of atomics on ARM
Reviewers: jfb, t.p.northover
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D5179
llvm-svn: 218329
2014-09-24 04:31:14 +08:00
|
|
|
// The trailing fence is emitted before the instruction instead of after
|
|
|
|
// because there is no easy way of setting Builder insertion point after
|
|
|
|
// an instruction. So we must erase it from the BB, and insert it back
|
|
|
|
// in the right place.
|
|
|
|
// We have a guard here because not every atomic operation generates a
|
|
|
|
// trailing fence.
|
|
|
|
if (TrailingFence) {
|
|
|
|
TrailingFence->removeFromParent();
|
|
|
|
TrailingFence->insertAfter(I);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (LeadingFence || TrailingFence);
|
|
|
|
}
|
|
|
|
|
2015-12-16 08:49:36 +08:00
|
|
|
/// Get the iX type with the same bitwidth as T.
|
|
|
|
IntegerType *AtomicExpand::getCorrespondingIntegerType(Type *T,
|
|
|
|
const DataLayout &DL) {
|
|
|
|
EVT VT = TLI->getValueType(DL, T);
|
|
|
|
unsigned BitWidth = VT.getStoreSizeInBits();
|
|
|
|
assert(BitWidth == VT.getSizeInBits() && "must be a power of two");
|
|
|
|
return IntegerType::get(T->getContext(), BitWidth);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Convert an atomic load of a non-integral type to an integer load of the
|
2016-02-19 08:06:41 +08:00
|
|
|
/// equivalent bitwidth. See the function comment on
|
2015-12-16 08:49:36 +08:00
|
|
|
/// convertAtomicStoreToIntegerType for background.
|
|
|
|
LoadInst *AtomicExpand::convertAtomicLoadToIntegerType(LoadInst *LI) {
|
|
|
|
auto *M = LI->getModule();
|
|
|
|
Type *NewTy = getCorrespondingIntegerType(LI->getType(),
|
|
|
|
M->getDataLayout());
|
|
|
|
|
|
|
|
IRBuilder<> Builder(LI);
|
|
|
|
|
|
|
|
Value *Addr = LI->getPointerOperand();
|
|
|
|
Type *PT = PointerType::get(NewTy,
|
|
|
|
Addr->getType()->getPointerAddressSpace());
|
|
|
|
Value *NewAddr = Builder.CreateBitCast(Addr, PT);
|
|
|
|
|
|
|
|
auto *NewLI = Builder.CreateLoad(NewAddr);
|
|
|
|
NewLI->setAlignment(LI->getAlignment());
|
|
|
|
NewLI->setVolatile(LI->isVolatile());
|
|
|
|
NewLI->setAtomic(LI->getOrdering(), LI->getSynchScope());
|
|
|
|
DEBUG(dbgs() << "Replaced " << *LI << " with " << *NewLI << "\n");
|
|
|
|
|
|
|
|
Value *NewVal = Builder.CreateBitCast(NewLI, LI->getType());
|
|
|
|
LI->replaceAllUsesWith(NewVal);
|
|
|
|
LI->eraseFromParent();
|
|
|
|
return NewLI;
|
|
|
|
}
|
|
|
|
|
2015-09-12 01:08:28 +08:00
|
|
|
bool AtomicExpand::tryExpandAtomicLoad(LoadInst *LI) {
|
|
|
|
switch (TLI->shouldExpandAtomicLoadInIR(LI)) {
|
|
|
|
case TargetLoweringBase::AtomicExpansionKind::None:
|
|
|
|
return false;
|
2015-12-03 02:12:57 +08:00
|
|
|
case TargetLoweringBase::AtomicExpansionKind::LLSC:
|
|
|
|
return expandAtomicOpToLLSC(
|
|
|
|
LI, LI->getPointerOperand(), LI->getOrdering(),
|
|
|
|
[](IRBuilder<> &Builder, Value *Loaded) { return Loaded; });
|
|
|
|
case TargetLoweringBase::AtomicExpansionKind::LLOnly:
|
2014-09-24 04:59:25 +08:00
|
|
|
return expandAtomicLoadToLL(LI);
|
2015-12-03 02:12:57 +08:00
|
|
|
case TargetLoweringBase::AtomicExpansionKind::CmpXChg:
|
2014-09-24 04:59:25 +08:00
|
|
|
return expandAtomicLoadToCmpXchg(LI);
|
2015-09-12 01:08:28 +08:00
|
|
|
}
|
|
|
|
llvm_unreachable("Unhandled case in tryExpandAtomicLoad");
|
2014-09-24 04:59:25 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
bool AtomicExpand::expandAtomicLoadToLL(LoadInst *LI) {
|
2014-09-04 05:01:03 +08:00
|
|
|
IRBuilder<> Builder(LI);
|
2014-04-03 19:44:58 +08:00
|
|
|
|
Add AtomicExpandPass::bracketInstWithFences, and use it whenever getInsertFencesForAtomic would trigger in SelectionDAGBuilder
Summary:
The goal is to eventually remove all the code related to getInsertFencesForAtomic
in SelectionDAGBuilder as it is wrong (designed for ARM, not really portable, works
mostly by accident because the backends are overly conservative), and repeats the
same logic that goes in emitLeading/TrailingFence.
In this patch, I make AtomicExpandPass insert the fences as it knows better
where to put them. Because this requires getting the fences and not just
passing an IRBuilder around, I had to change the return type of
emitLeading/TrailingFence.
This code only triggers on ARM for now. Because it is earlier in the pipeline
than SelectionDAGBuilder, it triggers and lowers atomic accesses to atomic so
SelectionDAGBuilder does not add barriers anymore on ARM.
If this patch is accepted I plan to implement emitLeading/TrailingFence for all
backends that setInsertFencesForAtomic(true), which will allow both making them
less conservative and simplifying SelectionDAGBuilder once they are all using
this interface.
This should not cause any functionnal change so the existing tests are used
and not modified.
Test Plan: make check-all, benefits from existing tests of atomics on ARM
Reviewers: jfb, t.p.northover
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D5179
llvm-svn: 218329
2014-09-24 04:31:14 +08:00
|
|
|
// On some architectures, load-linked instructions are atomic for larger
|
|
|
|
// sizes than normal loads. For example, the only 64-bit load guaranteed
|
|
|
|
// to be single-copy atomic by ARM is an ldrexd (A3.5.3).
|
2014-09-04 05:01:03 +08:00
|
|
|
Value *Val =
|
Add AtomicExpandPass::bracketInstWithFences, and use it whenever getInsertFencesForAtomic would trigger in SelectionDAGBuilder
Summary:
The goal is to eventually remove all the code related to getInsertFencesForAtomic
in SelectionDAGBuilder as it is wrong (designed for ARM, not really portable, works
mostly by accident because the backends are overly conservative), and repeats the
same logic that goes in emitLeading/TrailingFence.
In this patch, I make AtomicExpandPass insert the fences as it knows better
where to put them. Because this requires getting the fences and not just
passing an IRBuilder around, I had to change the return type of
emitLeading/TrailingFence.
This code only triggers on ARM for now. Because it is earlier in the pipeline
than SelectionDAGBuilder, it triggers and lowers atomic accesses to atomic so
SelectionDAGBuilder does not add barriers anymore on ARM.
If this patch is accepted I plan to implement emitLeading/TrailingFence for all
backends that setInsertFencesForAtomic(true), which will allow both making them
less conservative and simplifying SelectionDAGBuilder once they are all using
this interface.
This should not cause any functionnal change so the existing tests are used
and not modified.
Test Plan: make check-all, benefits from existing tests of atomics on ARM
Reviewers: jfb, t.p.northover
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D5179
llvm-svn: 218329
2014-09-24 04:31:14 +08:00
|
|
|
TLI->emitLoadLinked(Builder, LI->getPointerOperand(), LI->getOrdering());
|
2015-12-03 02:12:57 +08:00
|
|
|
TLI->emitAtomicCmpXchgNoStoreLLBalance(Builder);
|
2014-04-03 19:44:58 +08:00
|
|
|
|
|
|
|
LI->replaceAllUsesWith(Val);
|
|
|
|
LI->eraseFromParent();
|
2014-09-24 04:59:25 +08:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool AtomicExpand::expandAtomicLoadToCmpXchg(LoadInst *LI) {
|
|
|
|
IRBuilder<> Builder(LI);
|
|
|
|
AtomicOrdering Order = LI->getOrdering();
|
|
|
|
Value *Addr = LI->getPointerOperand();
|
|
|
|
Type *Ty = cast<PointerType>(Addr->getType())->getElementType();
|
|
|
|
Constant *DummyVal = Constant::getNullValue(Ty);
|
|
|
|
|
|
|
|
Value *Pair = Builder.CreateAtomicCmpXchg(
|
|
|
|
Addr, DummyVal, DummyVal, Order,
|
|
|
|
AtomicCmpXchgInst::getStrongestFailureOrdering(Order));
|
|
|
|
Value *Loaded = Builder.CreateExtractValue(Pair, 0, "loaded");
|
|
|
|
|
|
|
|
LI->replaceAllUsesWith(Loaded);
|
|
|
|
LI->eraseFromParent();
|
2014-04-03 19:44:58 +08:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-12-16 08:49:36 +08:00
|
|
|
/// Convert an atomic store of a non-integral type to an integer store of the
|
2016-02-19 08:06:41 +08:00
|
|
|
/// equivalent bitwidth. We used to not support floating point or vector
|
2015-12-16 08:49:36 +08:00
|
|
|
/// atomics in the IR at all. The backends learned to deal with the bitcast
|
|
|
|
/// idiom because that was the only way of expressing the notion of a atomic
|
|
|
|
/// float or vector store. The long term plan is to teach each backend to
|
|
|
|
/// instruction select from the original atomic store, but as a migration
|
|
|
|
/// mechanism, we convert back to the old format which the backends understand.
|
|
|
|
/// Each backend will need individual work to recognize the new format.
|
|
|
|
StoreInst *AtomicExpand::convertAtomicStoreToIntegerType(StoreInst *SI) {
|
|
|
|
IRBuilder<> Builder(SI);
|
|
|
|
auto *M = SI->getModule();
|
|
|
|
Type *NewTy = getCorrespondingIntegerType(SI->getValueOperand()->getType(),
|
|
|
|
M->getDataLayout());
|
|
|
|
Value *NewVal = Builder.CreateBitCast(SI->getValueOperand(), NewTy);
|
|
|
|
|
|
|
|
Value *Addr = SI->getPointerOperand();
|
|
|
|
Type *PT = PointerType::get(NewTy,
|
|
|
|
Addr->getType()->getPointerAddressSpace());
|
|
|
|
Value *NewAddr = Builder.CreateBitCast(Addr, PT);
|
|
|
|
|
|
|
|
StoreInst *NewSI = Builder.CreateStore(NewVal, NewAddr);
|
|
|
|
NewSI->setAlignment(SI->getAlignment());
|
|
|
|
NewSI->setVolatile(SI->isVolatile());
|
|
|
|
NewSI->setAtomic(SI->getOrdering(), SI->getSynchScope());
|
|
|
|
DEBUG(dbgs() << "Replaced " << *SI << " with " << *NewSI << "\n");
|
|
|
|
SI->eraseFromParent();
|
|
|
|
return NewSI;
|
|
|
|
}
|
|
|
|
|
2014-08-22 05:50:01 +08:00
|
|
|
bool AtomicExpand::expandAtomicStore(StoreInst *SI) {
|
2014-09-17 08:06:58 +08:00
|
|
|
// This function is only called on atomic stores that are too large to be
|
|
|
|
// atomic if implemented as a native store. So we replace them by an
|
|
|
|
// atomic swap, that can be implemented for example as a ldrex/strex on ARM
|
|
|
|
// or lock cmpxchg8/16b on X86, as these are atomic for larger sizes.
|
Mutate TargetLowering::shouldExpandAtomicRMWInIR to specifically dictate how AtomicRMWInsts are expanded.
Summary:
In PNaCl, most atomic instructions have their own @llvm.nacl.atomic.* function, each one, with a few exceptions, represents a consistent behaviour across all NaCl-supported targets. Unfortunately, the atomic RMW operations nand, [u]min, and [u]max aren't directly represented by any such @llvm.nacl.atomic.* function. This patch refines shouldExpandAtomicRMWInIR in TargetLowering so that a future `Le32TargetLowering` class can selectively inform the caller how the target desires the atomic RMW instruction to be expanded (ie via load-linked/store-conditional for ARM/AArch64, via cmpxchg for X86/others?, or not at all for Mips) if at all.
This does not represent a behavioural change and as such no tests were added.
Patch by: Richard Diamond.
Reviewers: jfb
Reviewed By: jfb
Subscribers: jfb, aemerson, t.p.northover, llvm-commits
Differential Revision: http://reviews.llvm.org/D7713
llvm-svn: 231250
2015-03-04 23:47:57 +08:00
|
|
|
// It is the responsibility of the target to only signal expansion via
|
2014-09-17 08:06:58 +08:00
|
|
|
// shouldExpandAtomicRMW in cases where this is required and possible.
|
2014-04-03 19:44:58 +08:00
|
|
|
IRBuilder<> Builder(SI);
|
|
|
|
AtomicRMWInst *AI =
|
|
|
|
Builder.CreateAtomicRMW(AtomicRMWInst::Xchg, SI->getPointerOperand(),
|
|
|
|
SI->getValueOperand(), SI->getOrdering());
|
|
|
|
SI->eraseFromParent();
|
|
|
|
|
|
|
|
// Now we have an appropriate swap instruction, lower it as usual.
|
Mutate TargetLowering::shouldExpandAtomicRMWInIR to specifically dictate how AtomicRMWInsts are expanded.
Summary:
In PNaCl, most atomic instructions have their own @llvm.nacl.atomic.* function, each one, with a few exceptions, represents a consistent behaviour across all NaCl-supported targets. Unfortunately, the atomic RMW operations nand, [u]min, and [u]max aren't directly represented by any such @llvm.nacl.atomic.* function. This patch refines shouldExpandAtomicRMWInIR in TargetLowering so that a future `Le32TargetLowering` class can selectively inform the caller how the target desires the atomic RMW instruction to be expanded (ie via load-linked/store-conditional for ARM/AArch64, via cmpxchg for X86/others?, or not at all for Mips) if at all.
This does not represent a behavioural change and as such no tests were added.
Patch by: Richard Diamond.
Reviewers: jfb
Reviewed By: jfb
Subscribers: jfb, aemerson, t.p.northover, llvm-commits
Differential Revision: http://reviews.llvm.org/D7713
llvm-svn: 231250
2015-03-04 23:47:57 +08:00
|
|
|
return tryExpandAtomicRMW(AI);
|
2014-04-03 19:44:58 +08:00
|
|
|
}
|
|
|
|
|
2015-08-03 23:29:47 +08:00
|
|
|
static void createCmpXchgInstFun(IRBuilder<> &Builder, Value *Addr,
|
|
|
|
Value *Loaded, Value *NewVal,
|
|
|
|
AtomicOrdering MemOpOrder,
|
|
|
|
Value *&Success, Value *&NewLoaded) {
|
|
|
|
Value* Pair = Builder.CreateAtomicCmpXchg(
|
|
|
|
Addr, Loaded, NewVal, MemOpOrder,
|
|
|
|
AtomicCmpXchgInst::getStrongestFailureOrdering(MemOpOrder));
|
|
|
|
Success = Builder.CreateExtractValue(Pair, 1, "success");
|
|
|
|
NewLoaded = Builder.CreateExtractValue(Pair, 0, "newloaded");
|
|
|
|
}
|
|
|
|
|
2014-09-17 08:06:58 +08:00
|
|
|
/// Emit IR to implement the given atomicrmw operation on values in registers,
|
|
|
|
/// returning the new value.
|
|
|
|
static Value *performAtomicOp(AtomicRMWInst::BinOp Op, IRBuilder<> &Builder,
|
|
|
|
Value *Loaded, Value *Inc) {
|
|
|
|
Value *NewVal;
|
|
|
|
switch (Op) {
|
|
|
|
case AtomicRMWInst::Xchg:
|
|
|
|
return Inc;
|
|
|
|
case AtomicRMWInst::Add:
|
|
|
|
return Builder.CreateAdd(Loaded, Inc, "new");
|
|
|
|
case AtomicRMWInst::Sub:
|
|
|
|
return Builder.CreateSub(Loaded, Inc, "new");
|
|
|
|
case AtomicRMWInst::And:
|
|
|
|
return Builder.CreateAnd(Loaded, Inc, "new");
|
|
|
|
case AtomicRMWInst::Nand:
|
|
|
|
return Builder.CreateNot(Builder.CreateAnd(Loaded, Inc), "new");
|
|
|
|
case AtomicRMWInst::Or:
|
|
|
|
return Builder.CreateOr(Loaded, Inc, "new");
|
|
|
|
case AtomicRMWInst::Xor:
|
|
|
|
return Builder.CreateXor(Loaded, Inc, "new");
|
|
|
|
case AtomicRMWInst::Max:
|
|
|
|
NewVal = Builder.CreateICmpSGT(Loaded, Inc);
|
|
|
|
return Builder.CreateSelect(NewVal, Loaded, Inc, "new");
|
|
|
|
case AtomicRMWInst::Min:
|
|
|
|
NewVal = Builder.CreateICmpSLE(Loaded, Inc);
|
|
|
|
return Builder.CreateSelect(NewVal, Loaded, Inc, "new");
|
|
|
|
case AtomicRMWInst::UMax:
|
|
|
|
NewVal = Builder.CreateICmpUGT(Loaded, Inc);
|
|
|
|
return Builder.CreateSelect(NewVal, Loaded, Inc, "new");
|
|
|
|
case AtomicRMWInst::UMin:
|
|
|
|
NewVal = Builder.CreateICmpULE(Loaded, Inc);
|
|
|
|
return Builder.CreateSelect(NewVal, Loaded, Inc, "new");
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unknown atomic op");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-03 02:12:57 +08:00
|
|
|
bool AtomicExpand::tryExpandAtomicRMW(AtomicRMWInst *AI) {
|
|
|
|
switch (TLI->shouldExpandAtomicRMWInIR(AI)) {
|
|
|
|
case TargetLoweringBase::AtomicExpansionKind::None:
|
|
|
|
return false;
|
|
|
|
case TargetLoweringBase::AtomicExpansionKind::LLSC:
|
|
|
|
return expandAtomicOpToLLSC(AI, AI->getPointerOperand(), AI->getOrdering(),
|
|
|
|
[&](IRBuilder<> &Builder, Value *Loaded) {
|
|
|
|
return performAtomicOp(AI->getOperation(),
|
|
|
|
Builder, Loaded,
|
|
|
|
AI->getValOperand());
|
|
|
|
});
|
|
|
|
case TargetLoweringBase::AtomicExpansionKind::CmpXChg:
|
|
|
|
return expandAtomicRMWToCmpXchg(AI, createCmpXchgInstFun);
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unhandled case in tryExpandAtomicRMW");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool AtomicExpand::expandAtomicOpToLLSC(
|
|
|
|
Instruction *I, Value *Addr, AtomicOrdering MemOpOrder,
|
|
|
|
std::function<Value *(IRBuilder<> &, Value *)> PerformOp) {
|
|
|
|
BasicBlock *BB = I->getParent();
|
2014-04-03 19:44:58 +08:00
|
|
|
Function *F = BB->getParent();
|
|
|
|
LLVMContext &Ctx = F->getContext();
|
|
|
|
|
|
|
|
// Given: atomicrmw some_op iN* %addr, iN %incr ordering
|
|
|
|
//
|
|
|
|
// The standard expansion we produce is:
|
|
|
|
// [...]
|
|
|
|
// fence?
|
|
|
|
// atomicrmw.start:
|
|
|
|
// %loaded = @load.linked(%addr)
|
|
|
|
// %new = some_op iN %loaded, %incr
|
|
|
|
// %stored = @store_conditional(%new, %addr)
|
|
|
|
// %try_again = icmp i32 ne %stored, 0
|
|
|
|
// br i1 %try_again, label %loop, label %atomicrmw.end
|
|
|
|
// atomicrmw.end:
|
|
|
|
// fence?
|
|
|
|
// [...]
|
2015-12-03 02:12:57 +08:00
|
|
|
BasicBlock *ExitBB = BB->splitBasicBlock(I->getIterator(), "atomicrmw.end");
|
2014-04-03 19:44:58 +08:00
|
|
|
BasicBlock *LoopBB = BasicBlock::Create(Ctx, "atomicrmw.start", F, ExitBB);
|
|
|
|
|
2015-12-03 02:12:57 +08:00
|
|
|
// This grabs the DebugLoc from I.
|
|
|
|
IRBuilder<> Builder(I);
|
2014-04-03 19:44:58 +08:00
|
|
|
|
|
|
|
// The split call above "helpfully" added a branch at the end of BB (to the
|
|
|
|
// wrong place), but we might want a fence too. It's easiest to just remove
|
|
|
|
// the branch entirely.
|
|
|
|
std::prev(BB->end())->eraseFromParent();
|
|
|
|
Builder.SetInsertPoint(BB);
|
|
|
|
Builder.CreateBr(LoopBB);
|
|
|
|
|
|
|
|
// Start the main loop block now that we've taken care of the preliminaries.
|
|
|
|
Builder.SetInsertPoint(LoopBB);
|
2014-09-04 05:01:03 +08:00
|
|
|
Value *Loaded = TLI->emitLoadLinked(Builder, Addr, MemOpOrder);
|
2014-04-03 19:44:58 +08:00
|
|
|
|
2015-12-03 02:12:57 +08:00
|
|
|
Value *NewVal = PerformOp(Builder, Loaded);
|
2014-04-03 19:44:58 +08:00
|
|
|
|
2014-08-05 05:25:23 +08:00
|
|
|
Value *StoreSuccess =
|
2014-09-04 05:01:03 +08:00
|
|
|
TLI->emitStoreConditional(Builder, NewVal, Addr, MemOpOrder);
|
2014-04-03 19:44:58 +08:00
|
|
|
Value *TryAgain = Builder.CreateICmpNE(
|
|
|
|
StoreSuccess, ConstantInt::get(IntegerType::get(Ctx, 32), 0), "tryagain");
|
|
|
|
Builder.CreateCondBr(TryAgain, LoopBB, ExitBB);
|
|
|
|
|
|
|
|
Builder.SetInsertPoint(ExitBB, ExitBB->begin());
|
|
|
|
|
2015-12-03 02:12:57 +08:00
|
|
|
I->replaceAllUsesWith(Loaded);
|
|
|
|
I->eraseFromParent();
|
2014-04-03 19:44:58 +08:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-02-19 08:06:41 +08:00
|
|
|
/// Convert an atomic cmpxchg of a non-integral type to an integer cmpxchg of
|
|
|
|
/// the equivalent bitwidth. We used to not support pointer cmpxchg in the
|
|
|
|
/// IR. As a migration step, we convert back to what use to be the standard
|
|
|
|
/// way to represent a pointer cmpxchg so that we can update backends one by
|
|
|
|
/// one.
|
|
|
|
AtomicCmpXchgInst *AtomicExpand::convertCmpXchgToIntegerType(AtomicCmpXchgInst *CI) {
|
|
|
|
auto *M = CI->getModule();
|
|
|
|
Type *NewTy = getCorrespondingIntegerType(CI->getCompareOperand()->getType(),
|
|
|
|
M->getDataLayout());
|
|
|
|
|
|
|
|
IRBuilder<> Builder(CI);
|
|
|
|
|
|
|
|
Value *Addr = CI->getPointerOperand();
|
|
|
|
Type *PT = PointerType::get(NewTy,
|
|
|
|
Addr->getType()->getPointerAddressSpace());
|
|
|
|
Value *NewAddr = Builder.CreateBitCast(Addr, PT);
|
|
|
|
|
|
|
|
Value *NewCmp = Builder.CreatePtrToInt(CI->getCompareOperand(), NewTy);
|
|
|
|
Value *NewNewVal = Builder.CreatePtrToInt(CI->getNewValOperand(), NewTy);
|
|
|
|
|
|
|
|
|
|
|
|
auto *NewCI = Builder.CreateAtomicCmpXchg(NewAddr, NewCmp, NewNewVal,
|
|
|
|
CI->getSuccessOrdering(),
|
|
|
|
CI->getFailureOrdering(),
|
|
|
|
CI->getSynchScope());
|
|
|
|
NewCI->setVolatile(CI->isVolatile());
|
|
|
|
NewCI->setWeak(CI->isWeak());
|
|
|
|
DEBUG(dbgs() << "Replaced " << *CI << " with " << *NewCI << "\n");
|
|
|
|
|
|
|
|
Value *OldVal = Builder.CreateExtractValue(NewCI, 0);
|
|
|
|
Value *Succ = Builder.CreateExtractValue(NewCI, 1);
|
|
|
|
|
|
|
|
OldVal = Builder.CreateIntToPtr(OldVal, CI->getCompareOperand()->getType());
|
|
|
|
|
|
|
|
Value *Res = UndefValue::get(CI->getType());
|
|
|
|
Res = Builder.CreateInsertValue(Res, OldVal, 0);
|
|
|
|
Res = Builder.CreateInsertValue(Res, Succ, 1);
|
|
|
|
|
|
|
|
CI->replaceAllUsesWith(Res);
|
|
|
|
CI->eraseFromParent();
|
|
|
|
return NewCI;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-08-22 05:50:01 +08:00
|
|
|
bool AtomicExpand::expandAtomicCmpXchg(AtomicCmpXchgInst *CI) {
|
2014-04-03 21:06:54 +08:00
|
|
|
AtomicOrdering SuccessOrder = CI->getSuccessOrdering();
|
|
|
|
AtomicOrdering FailureOrder = CI->getFailureOrdering();
|
2014-04-03 19:44:58 +08:00
|
|
|
Value *Addr = CI->getPointerOperand();
|
|
|
|
BasicBlock *BB = CI->getParent();
|
|
|
|
Function *F = BB->getParent();
|
|
|
|
LLVMContext &Ctx = F->getContext();
|
2014-09-04 05:29:59 +08:00
|
|
|
// If getInsertFencesForAtomic() returns true, then the target does not want
|
|
|
|
// to deal with memory orders, and emitLeading/TrailingFence should take care
|
|
|
|
// of everything. Otherwise, emitLeading/TrailingFence are no-op and we
|
|
|
|
// should preserve the ordering.
|
2014-09-04 05:01:03 +08:00
|
|
|
AtomicOrdering MemOpOrder =
|
|
|
|
TLI->getInsertFencesForAtomic() ? Monotonic : SuccessOrder;
|
2014-04-03 19:44:58 +08:00
|
|
|
|
2016-02-23 04:55:50 +08:00
|
|
|
// In implementations which use a barrier to achieve release semantics, we can
|
|
|
|
// delay emitting this barrier until we know a store is actually going to be
|
|
|
|
// attempted. The cost of this delay is that we need 2 copies of the block
|
|
|
|
// emitting the load-linked, affecting code size.
|
|
|
|
//
|
|
|
|
// Ideally, this logic would be unconditional except for the minsize check
|
|
|
|
// since in other cases the extra blocks naturally collapse down to the
|
|
|
|
// minimal loop. Unfortunately, this puts too much stress on later
|
|
|
|
// optimisations so we avoid emitting the extra logic in those cases too.
|
|
|
|
bool HasReleasedLoadBB = !CI->isWeak() && TLI->getInsertFencesForAtomic() &&
|
|
|
|
SuccessOrder != Monotonic &&
|
|
|
|
SuccessOrder != Acquire && !F->optForMinSize();
|
|
|
|
|
|
|
|
// There's no overhead for sinking the release barrier in a weak cmpxchg, so
|
|
|
|
// do it even on minsize.
|
|
|
|
bool UseUnconditionalReleaseBarrier = F->optForMinSize() && !CI->isWeak();
|
|
|
|
|
2014-04-03 19:44:58 +08:00
|
|
|
// Given: cmpxchg some_op iN* %addr, iN %desired, iN %new success_ord fail_ord
|
|
|
|
//
|
2014-04-03 21:06:54 +08:00
|
|
|
// The full expansion we produce is:
|
2014-04-03 19:44:58 +08:00
|
|
|
// [...]
|
|
|
|
// cmpxchg.start:
|
2016-02-23 04:55:50 +08:00
|
|
|
// %unreleasedload = @load.linked(%addr)
|
|
|
|
// %should_store = icmp eq %unreleasedload, %desired
|
|
|
|
// br i1 %should_store, label %cmpxchg.fencedstore,
|
2015-09-23 01:21:44 +08:00
|
|
|
// label %cmpxchg.nostore
|
2016-02-23 04:55:50 +08:00
|
|
|
// cmpxchg.releasingstore:
|
|
|
|
// fence?
|
|
|
|
// br label cmpxchg.trystore
|
2014-04-03 19:44:58 +08:00
|
|
|
// cmpxchg.trystore:
|
2016-02-23 04:55:50 +08:00
|
|
|
// %loaded.trystore = phi [%unreleasedload, %releasingstore],
|
|
|
|
// [%releasedload, %cmpxchg.releasedload]
|
2014-04-03 19:44:58 +08:00
|
|
|
// %stored = @store_conditional(%new, %addr)
|
2014-06-14 00:45:52 +08:00
|
|
|
// %success = icmp eq i32 %stored, 0
|
2016-02-23 04:55:50 +08:00
|
|
|
// br i1 %success, label %cmpxchg.success,
|
|
|
|
// label %cmpxchg.releasedload/%cmpxchg.failure
|
|
|
|
// cmpxchg.releasedload:
|
|
|
|
// %releasedload = @load.linked(%addr)
|
|
|
|
// %should_store = icmp eq %releasedload, %desired
|
|
|
|
// br i1 %should_store, label %cmpxchg.trystore,
|
|
|
|
// label %cmpxchg.failure
|
2014-06-14 00:45:52 +08:00
|
|
|
// cmpxchg.success:
|
|
|
|
// fence?
|
|
|
|
// br label %cmpxchg.end
|
2015-09-23 01:21:44 +08:00
|
|
|
// cmpxchg.nostore:
|
2016-02-23 04:55:50 +08:00
|
|
|
// %loaded.nostore = phi [%unreleasedload, %cmpxchg.start],
|
|
|
|
// [%releasedload,
|
|
|
|
// %cmpxchg.releasedload/%cmpxchg.trystore]
|
2015-09-23 01:21:44 +08:00
|
|
|
// @load_linked_fail_balance()?
|
|
|
|
// br label %cmpxchg.failure
|
2014-06-14 00:45:52 +08:00
|
|
|
// cmpxchg.failure:
|
2014-04-03 19:44:58 +08:00
|
|
|
// fence?
|
2014-04-03 21:06:54 +08:00
|
|
|
// br label %cmpxchg.end
|
|
|
|
// cmpxchg.end:
|
2016-02-23 04:55:50 +08:00
|
|
|
// %loaded = phi [%loaded.nostore, %cmpxchg.failure],
|
|
|
|
// [%loaded.trystore, %cmpxchg.trystore]
|
2014-06-14 00:45:52 +08:00
|
|
|
// %success = phi i1 [true, %cmpxchg.success], [false, %cmpxchg.failure]
|
|
|
|
// %restmp = insertvalue { iN, i1 } undef, iN %loaded, 0
|
|
|
|
// %res = insertvalue { iN, i1 } %restmp, i1 %success, 1
|
2014-04-03 19:44:58 +08:00
|
|
|
// [...]
|
2015-10-10 00:54:49 +08:00
|
|
|
BasicBlock *ExitBB = BB->splitBasicBlock(CI->getIterator(), "cmpxchg.end");
|
2014-06-14 00:45:52 +08:00
|
|
|
auto FailureBB = BasicBlock::Create(Ctx, "cmpxchg.failure", F, ExitBB);
|
2015-09-23 01:21:44 +08:00
|
|
|
auto NoStoreBB = BasicBlock::Create(Ctx, "cmpxchg.nostore", F, FailureBB);
|
|
|
|
auto SuccessBB = BasicBlock::Create(Ctx, "cmpxchg.success", F, NoStoreBB);
|
2016-02-23 04:55:50 +08:00
|
|
|
auto ReleasedLoadBB =
|
|
|
|
BasicBlock::Create(Ctx, "cmpxchg.releasedload", F, SuccessBB);
|
|
|
|
auto TryStoreBB =
|
|
|
|
BasicBlock::Create(Ctx, "cmpxchg.trystore", F, ReleasedLoadBB);
|
|
|
|
auto ReleasingStoreBB =
|
|
|
|
BasicBlock::Create(Ctx, "cmpxchg.fencedstore", F, TryStoreBB);
|
|
|
|
auto StartBB = BasicBlock::Create(Ctx, "cmpxchg.start", F, ReleasingStoreBB);
|
2014-04-03 19:44:58 +08:00
|
|
|
|
|
|
|
// This grabs the DebugLoc from CI
|
|
|
|
IRBuilder<> Builder(CI);
|
|
|
|
|
|
|
|
// The split call above "helpfully" added a branch at the end of BB (to the
|
|
|
|
// wrong place), but we might want a fence too. It's easiest to just remove
|
|
|
|
// the branch entirely.
|
|
|
|
std::prev(BB->end())->eraseFromParent();
|
|
|
|
Builder.SetInsertPoint(BB);
|
2016-02-23 04:55:50 +08:00
|
|
|
if (UseUnconditionalReleaseBarrier)
|
|
|
|
TLI->emitLeadingFence(Builder, SuccessOrder, /*IsStore=*/true,
|
|
|
|
/*IsLoad=*/true);
|
|
|
|
Builder.CreateBr(StartBB);
|
2014-04-03 19:44:58 +08:00
|
|
|
|
|
|
|
// Start the main loop block now that we've taken care of the preliminaries.
|
2016-02-23 04:55:50 +08:00
|
|
|
Builder.SetInsertPoint(StartBB);
|
|
|
|
Value *UnreleasedLoad = TLI->emitLoadLinked(Builder, Addr, MemOpOrder);
|
|
|
|
Value *ShouldStore = Builder.CreateICmpEQ(
|
|
|
|
UnreleasedLoad, CI->getCompareOperand(), "should_store");
|
2014-04-03 21:06:54 +08:00
|
|
|
|
2015-06-19 09:53:21 +08:00
|
|
|
// If the cmpxchg doesn't actually need any ordering when it fails, we can
|
2014-04-03 21:06:54 +08:00
|
|
|
// jump straight past that fence instruction (if it exists).
|
2016-02-23 04:55:50 +08:00
|
|
|
Builder.CreateCondBr(ShouldStore, ReleasingStoreBB, NoStoreBB);
|
|
|
|
|
|
|
|
Builder.SetInsertPoint(ReleasingStoreBB);
|
|
|
|
if (!UseUnconditionalReleaseBarrier)
|
|
|
|
TLI->emitLeadingFence(Builder, SuccessOrder, /*IsStore=*/true,
|
|
|
|
/*IsLoad=*/true);
|
|
|
|
Builder.CreateBr(TryStoreBB);
|
2014-04-03 19:44:58 +08:00
|
|
|
|
|
|
|
Builder.SetInsertPoint(TryStoreBB);
|
2014-09-04 05:01:03 +08:00
|
|
|
Value *StoreSuccess = TLI->emitStoreConditional(
|
|
|
|
Builder, CI->getNewValOperand(), Addr, MemOpOrder);
|
2014-06-14 00:45:36 +08:00
|
|
|
StoreSuccess = Builder.CreateICmpEQ(
|
2014-04-03 19:44:58 +08:00
|
|
|
StoreSuccess, ConstantInt::get(Type::getInt32Ty(Ctx), 0), "success");
|
2016-02-23 04:55:50 +08:00
|
|
|
BasicBlock *RetryBB = HasReleasedLoadBB ? ReleasedLoadBB : StartBB;
|
2014-06-14 00:45:52 +08:00
|
|
|
Builder.CreateCondBr(StoreSuccess, SuccessBB,
|
2016-02-23 04:55:50 +08:00
|
|
|
CI->isWeak() ? FailureBB : RetryBB);
|
|
|
|
|
|
|
|
Builder.SetInsertPoint(ReleasedLoadBB);
|
|
|
|
Value *SecondLoad;
|
|
|
|
if (HasReleasedLoadBB) {
|
|
|
|
SecondLoad = TLI->emitLoadLinked(Builder, Addr, MemOpOrder);
|
|
|
|
ShouldStore = Builder.CreateICmpEQ(SecondLoad, CI->getCompareOperand(),
|
|
|
|
"should_store");
|
|
|
|
|
|
|
|
// If the cmpxchg doesn't actually need any ordering when it fails, we can
|
|
|
|
// jump straight past that fence instruction (if it exists).
|
|
|
|
Builder.CreateCondBr(ShouldStore, TryStoreBB, NoStoreBB);
|
|
|
|
} else
|
|
|
|
Builder.CreateUnreachable();
|
|
|
|
|
|
|
|
// Make sure later instructions don't get reordered with a fence if
|
|
|
|
// necessary.
|
2014-06-14 00:45:52 +08:00
|
|
|
Builder.SetInsertPoint(SuccessBB);
|
2014-09-04 05:01:03 +08:00
|
|
|
TLI->emitTrailingFence(Builder, SuccessOrder, /*IsStore=*/true,
|
|
|
|
/*IsLoad=*/true);
|
2014-04-03 21:06:54 +08:00
|
|
|
Builder.CreateBr(ExitBB);
|
2014-04-03 19:44:58 +08:00
|
|
|
|
2015-09-23 01:21:44 +08:00
|
|
|
Builder.SetInsertPoint(NoStoreBB);
|
|
|
|
// In the failing case, where we don't execute the store-conditional, the
|
|
|
|
// target might want to balance out the load-linked with a dedicated
|
|
|
|
// instruction (e.g., on ARM, clearing the exclusive monitor).
|
|
|
|
TLI->emitAtomicCmpXchgNoStoreLLBalance(Builder);
|
|
|
|
Builder.CreateBr(FailureBB);
|
|
|
|
|
2014-06-14 00:45:52 +08:00
|
|
|
Builder.SetInsertPoint(FailureBB);
|
2014-09-04 05:01:03 +08:00
|
|
|
TLI->emitTrailingFence(Builder, FailureOrder, /*IsStore=*/true,
|
|
|
|
/*IsLoad=*/true);
|
2014-06-14 00:45:52 +08:00
|
|
|
Builder.CreateBr(ExitBB);
|
|
|
|
|
2014-05-30 18:09:59 +08:00
|
|
|
// Finally, we have control-flow based knowledge of whether the cmpxchg
|
|
|
|
// succeeded or not. We expose this to later passes by converting any
|
2016-02-23 04:55:50 +08:00
|
|
|
// subsequent "icmp eq/ne %loaded, %oldval" into a use of an appropriate
|
|
|
|
// PHI.
|
2014-06-14 00:45:52 +08:00
|
|
|
Builder.SetInsertPoint(ExitBB, ExitBB->begin());
|
IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
2014-06-13 22:24:07 +08:00
|
|
|
PHINode *Success = Builder.CreatePHI(Type::getInt1Ty(Ctx), 2);
|
|
|
|
Success->addIncoming(ConstantInt::getTrue(Ctx), SuccessBB);
|
2014-06-14 00:45:52 +08:00
|
|
|
Success->addIncoming(ConstantInt::getFalse(Ctx), FailureBB);
|
2014-05-30 18:09:59 +08:00
|
|
|
|
2016-02-23 04:55:50 +08:00
|
|
|
// Setup the builder so we can create any PHIs we need.
|
|
|
|
Value *Loaded;
|
|
|
|
if (!HasReleasedLoadBB)
|
|
|
|
Loaded = UnreleasedLoad;
|
|
|
|
else {
|
|
|
|
Builder.SetInsertPoint(TryStoreBB, TryStoreBB->begin());
|
|
|
|
PHINode *TryStoreLoaded = Builder.CreatePHI(UnreleasedLoad->getType(), 2);
|
|
|
|
TryStoreLoaded->addIncoming(UnreleasedLoad, ReleasingStoreBB);
|
|
|
|
TryStoreLoaded->addIncoming(SecondLoad, ReleasedLoadBB);
|
|
|
|
|
|
|
|
Builder.SetInsertPoint(NoStoreBB, NoStoreBB->begin());
|
|
|
|
PHINode *NoStoreLoaded = Builder.CreatePHI(UnreleasedLoad->getType(), 2);
|
|
|
|
NoStoreLoaded->addIncoming(UnreleasedLoad, StartBB);
|
|
|
|
NoStoreLoaded->addIncoming(SecondLoad, ReleasedLoadBB);
|
|
|
|
|
|
|
|
Builder.SetInsertPoint(ExitBB, ++ExitBB->begin());
|
|
|
|
PHINode *ExitLoaded = Builder.CreatePHI(UnreleasedLoad->getType(), 2);
|
|
|
|
ExitLoaded->addIncoming(TryStoreLoaded, SuccessBB);
|
|
|
|
ExitLoaded->addIncoming(NoStoreLoaded, FailureBB);
|
|
|
|
|
|
|
|
Loaded = ExitLoaded;
|
|
|
|
}
|
|
|
|
|
2014-05-30 18:09:59 +08:00
|
|
|
// Look for any users of the cmpxchg that are just comparing the loaded value
|
|
|
|
// against the desired one, and replace them with the CFG-derived version.
|
IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
2014-06-13 22:24:07 +08:00
|
|
|
SmallVector<ExtractValueInst *, 2> PrunedInsts;
|
2014-05-30 18:09:59 +08:00
|
|
|
for (auto User : CI->users()) {
|
IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
2014-06-13 22:24:07 +08:00
|
|
|
ExtractValueInst *EV = dyn_cast<ExtractValueInst>(User);
|
|
|
|
if (!EV)
|
2014-05-30 18:09:59 +08:00
|
|
|
continue;
|
|
|
|
|
IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
2014-06-13 22:24:07 +08:00
|
|
|
assert(EV->getNumIndices() == 1 && EV->getIndices()[0] <= 1 &&
|
|
|
|
"weird extraction from { iN, i1 }");
|
2014-05-30 18:09:59 +08:00
|
|
|
|
IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
2014-06-13 22:24:07 +08:00
|
|
|
if (EV->getIndices()[0] == 0)
|
|
|
|
EV->replaceAllUsesWith(Loaded);
|
|
|
|
else
|
|
|
|
EV->replaceAllUsesWith(Success);
|
|
|
|
|
|
|
|
PrunedInsts.push_back(EV);
|
2014-05-30 18:09:59 +08:00
|
|
|
}
|
|
|
|
|
IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
2014-06-13 22:24:07 +08:00
|
|
|
// We can remove the instructions now we're no longer iterating through them.
|
|
|
|
for (auto EV : PrunedInsts)
|
|
|
|
EV->eraseFromParent();
|
2014-04-03 19:44:58 +08:00
|
|
|
|
IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.
As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.
At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.
By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.
Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.
Summary for out of tree users:
------------------------------
+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.
llvm-svn: 210903
2014-06-13 22:24:07 +08:00
|
|
|
if (!CI->use_empty()) {
|
|
|
|
// Some use of the full struct return that we don't understand has happened,
|
|
|
|
// so we've got to reconstruct it properly.
|
|
|
|
Value *Res;
|
|
|
|
Res = Builder.CreateInsertValue(UndefValue::get(CI->getType()), Loaded, 0);
|
|
|
|
Res = Builder.CreateInsertValue(Res, Success, 1);
|
|
|
|
|
|
|
|
CI->replaceAllUsesWith(Res);
|
|
|
|
}
|
|
|
|
|
|
|
|
CI->eraseFromParent();
|
2014-04-03 19:44:58 +08:00
|
|
|
return true;
|
|
|
|
}
|
2014-09-26 01:27:43 +08:00
|
|
|
|
|
|
|
bool AtomicExpand::isIdempotentRMW(AtomicRMWInst* RMWI) {
|
|
|
|
auto C = dyn_cast<ConstantInt>(RMWI->getValOperand());
|
|
|
|
if(!C)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
AtomicRMWInst::BinOp Op = RMWI->getOperation();
|
|
|
|
switch(Op) {
|
|
|
|
case AtomicRMWInst::Add:
|
|
|
|
case AtomicRMWInst::Sub:
|
|
|
|
case AtomicRMWInst::Or:
|
|
|
|
case AtomicRMWInst::Xor:
|
|
|
|
return C->isZero();
|
|
|
|
case AtomicRMWInst::And:
|
|
|
|
return C->isMinusOne();
|
|
|
|
// FIXME: we could also treat Min/Max/UMin/UMax by the INT_MIN/INT_MAX/...
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool AtomicExpand::simplifyIdempotentRMW(AtomicRMWInst* RMWI) {
|
2015-09-13 02:51:23 +08:00
|
|
|
if (auto ResultingLoad = TLI->lowerIdempotentRMWIntoFencedLoad(RMWI)) {
|
|
|
|
tryExpandAtomicLoad(ResultingLoad);
|
|
|
|
return true;
|
|
|
|
}
|
2014-09-26 01:27:43 +08:00
|
|
|
return false;
|
|
|
|
}
|
2015-08-03 23:29:47 +08:00
|
|
|
|
|
|
|
bool llvm::expandAtomicRMWToCmpXchg(AtomicRMWInst *AI,
|
|
|
|
CreateCmpXchgInstFun CreateCmpXchg) {
|
|
|
|
assert(AI);
|
|
|
|
|
|
|
|
AtomicOrdering MemOpOrder =
|
|
|
|
AI->getOrdering() == Unordered ? Monotonic : AI->getOrdering();
|
|
|
|
Value *Addr = AI->getPointerOperand();
|
|
|
|
BasicBlock *BB = AI->getParent();
|
|
|
|
Function *F = BB->getParent();
|
|
|
|
LLVMContext &Ctx = F->getContext();
|
|
|
|
|
|
|
|
// Given: atomicrmw some_op iN* %addr, iN %incr ordering
|
|
|
|
//
|
|
|
|
// The standard expansion we produce is:
|
|
|
|
// [...]
|
|
|
|
// %init_loaded = load atomic iN* %addr
|
|
|
|
// br label %loop
|
|
|
|
// loop:
|
|
|
|
// %loaded = phi iN [ %init_loaded, %entry ], [ %new_loaded, %loop ]
|
|
|
|
// %new = some_op iN %loaded, %incr
|
|
|
|
// %pair = cmpxchg iN* %addr, iN %loaded, iN %new
|
|
|
|
// %new_loaded = extractvalue { iN, i1 } %pair, 0
|
|
|
|
// %success = extractvalue { iN, i1 } %pair, 1
|
|
|
|
// br i1 %success, label %atomicrmw.end, label %loop
|
|
|
|
// atomicrmw.end:
|
|
|
|
// [...]
|
2015-10-10 00:54:49 +08:00
|
|
|
BasicBlock *ExitBB = BB->splitBasicBlock(AI->getIterator(), "atomicrmw.end");
|
2015-08-03 23:29:47 +08:00
|
|
|
BasicBlock *LoopBB = BasicBlock::Create(Ctx, "atomicrmw.start", F, ExitBB);
|
|
|
|
|
|
|
|
// This grabs the DebugLoc from AI.
|
|
|
|
IRBuilder<> Builder(AI);
|
|
|
|
|
|
|
|
// The split call above "helpfully" added a branch at the end of BB (to the
|
|
|
|
// wrong place), but we want a load. It's easiest to just remove
|
|
|
|
// the branch entirely.
|
|
|
|
std::prev(BB->end())->eraseFromParent();
|
|
|
|
Builder.SetInsertPoint(BB);
|
|
|
|
LoadInst *InitLoaded = Builder.CreateLoad(Addr);
|
|
|
|
// Atomics require at least natural alignment.
|
2015-08-07 00:55:03 +08:00
|
|
|
InitLoaded->setAlignment(AI->getType()->getPrimitiveSizeInBits() / 8);
|
2015-08-03 23:29:47 +08:00
|
|
|
Builder.CreateBr(LoopBB);
|
|
|
|
|
|
|
|
// Start the main loop block now that we've taken care of the preliminaries.
|
|
|
|
Builder.SetInsertPoint(LoopBB);
|
|
|
|
PHINode *Loaded = Builder.CreatePHI(AI->getType(), 2, "loaded");
|
|
|
|
Loaded->addIncoming(InitLoaded, BB);
|
|
|
|
|
|
|
|
Value *NewVal =
|
|
|
|
performAtomicOp(AI->getOperation(), Builder, Loaded, AI->getValOperand());
|
|
|
|
|
|
|
|
Value *NewLoaded = nullptr;
|
|
|
|
Value *Success = nullptr;
|
|
|
|
|
|
|
|
CreateCmpXchg(Builder, Addr, Loaded, NewVal, MemOpOrder,
|
|
|
|
Success, NewLoaded);
|
|
|
|
assert(Success && NewLoaded);
|
|
|
|
|
|
|
|
Loaded->addIncoming(NewLoaded, LoopBB);
|
|
|
|
|
|
|
|
Builder.CreateCondBr(Success, ExitBB, LoopBB);
|
|
|
|
|
|
|
|
Builder.SetInsertPoint(ExitBB, ExitBB->begin());
|
|
|
|
|
|
|
|
AI->replaceAllUsesWith(NewLoaded);
|
|
|
|
AI->eraseFromParent();
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|