2008-11-07 18:59:00 +08:00
|
|
|
//===-- XCoreTargetMachine.cpp - Define TargetMachine for XCore -----------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2017-06-06 19:49:48 +08:00
|
|
|
#include "XCoreTargetMachine.h"
|
2017-01-25 07:02:48 +08:00
|
|
|
#include "MCTargetDesc/XCoreMCTargetDesc.h"
|
|
|
|
#include "XCore.h"
|
2014-11-13 17:26:31 +08:00
|
|
|
#include "XCoreTargetObjectFile.h"
|
2015-01-31 19:17:59 +08:00
|
|
|
#include "XCoreTargetTransformInfo.h"
|
2017-01-25 07:02:48 +08:00
|
|
|
#include "llvm/ADT/Optional.h"
|
|
|
|
#include "llvm/ADT/STLExtras.h"
|
|
|
|
#include "llvm/Analysis/TargetTransformInfo.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/CodeGen/Passes.h"
|
2016-05-10 11:21:59 +08:00
|
|
|
#include "llvm/CodeGen/TargetPassConfig.h"
|
2017-01-25 07:02:48 +08:00
|
|
|
#include "llvm/Support/CodeGen.h"
|
2011-08-25 02:08:43 +08:00
|
|
|
#include "llvm/Support/TargetRegistry.h"
|
2017-01-25 07:02:48 +08:00
|
|
|
|
2008-11-07 18:59:00 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2016-05-19 06:04:49 +08:00
|
|
|
static Reloc::Model getEffectiveRelocModel(Optional<Reloc::Model> RM) {
|
|
|
|
if (!RM.hasValue())
|
|
|
|
return Reloc::Static;
|
|
|
|
return *RM;
|
|
|
|
}
|
|
|
|
|
2017-08-03 10:16:21 +08:00
|
|
|
static CodeModel::Model getEffectiveCodeModel(Optional<CodeModel::Model> CM) {
|
|
|
|
if (CM) {
|
|
|
|
if (*CM != CodeModel::Small && *CM != CodeModel::Large)
|
|
|
|
report_fatal_error("Target only supports CodeModel Small or Large");
|
|
|
|
return *CM;
|
|
|
|
}
|
|
|
|
return CodeModel::Small;
|
|
|
|
}
|
|
|
|
|
2016-05-19 00:00:24 +08:00
|
|
|
/// Create an ILP32 architecture model
|
2008-11-07 18:59:00 +08:00
|
|
|
///
|
2015-06-12 03:41:26 +08:00
|
|
|
XCoreTargetMachine::XCoreTargetMachine(const Target &T, const Triple &TT,
|
2011-07-20 15:51:56 +08:00
|
|
|
StringRef CPU, StringRef FS,
|
2011-12-03 06:16:29 +08:00
|
|
|
const TargetOptions &Options,
|
2016-05-19 06:04:49 +08:00
|
|
|
Optional<Reloc::Model> RM,
|
2017-08-03 10:16:21 +08:00
|
|
|
Optional<CodeModel::Model> CM,
|
|
|
|
CodeGenOpt::Level OL, bool JIT)
|
2017-10-13 06:57:28 +08:00
|
|
|
: LLVMTargetMachine(
|
2015-03-12 08:07:24 +08:00
|
|
|
T, "e-m:e-p:32:32-i1:8:32-i8:8:32-i16:16:32-i64:32-f64:32-a:0:32-n32",
|
2017-08-03 10:16:21 +08:00
|
|
|
TT, CPU, FS, Options, getEffectiveRelocModel(RM),
|
|
|
|
getEffectiveCodeModel(CM), OL),
|
2017-01-25 07:02:48 +08:00
|
|
|
TLOF(llvm::make_unique<XCoreTargetObjectFile>()),
|
2015-06-12 03:41:26 +08:00
|
|
|
Subtarget(TT, CPU, FS, *this) {
|
2013-05-13 09:16:13 +08:00
|
|
|
initAsmInfo();
|
2008-11-07 18:59:00 +08:00
|
|
|
}
|
|
|
|
|
2017-01-25 07:02:48 +08:00
|
|
|
XCoreTargetMachine::~XCoreTargetMachine() = default;
|
2014-11-21 07:37:18 +08:00
|
|
|
|
2012-02-03 13:12:41 +08:00
|
|
|
namespace {
|
2017-01-25 07:02:48 +08:00
|
|
|
|
2012-02-03 13:12:41 +08:00
|
|
|
/// XCore Code Generator Pass Configuration Options.
|
|
|
|
class XCorePassConfig : public TargetPassConfig {
|
|
|
|
public:
|
2017-05-31 05:36:41 +08:00
|
|
|
XCorePassConfig(XCoreTargetMachine &TM, PassManagerBase &PM)
|
2012-02-04 10:56:59 +08:00
|
|
|
: TargetPassConfig(TM, PM) {}
|
2012-02-03 13:12:41 +08:00
|
|
|
|
|
|
|
XCoreTargetMachine &getXCoreTargetMachine() const {
|
|
|
|
return getTM<XCoreTargetMachine>();
|
|
|
|
}
|
|
|
|
|
Erase fence insertion from SelectionDAGBuilder.cpp (NFC)
Summary:
Backends can use setInsertFencesForAtomic to signal to the middle-end that
montonic is the only memory ordering they can accept for
stores/loads/rmws/cmpxchg. The code lowering those accesses with a stronger
ordering to fences + monotonic accesses is currently living in
SelectionDAGBuilder.cpp. In this patch I propose moving this logic out of it
for several reasons:
- There is lots of redundancy to avoid: extremely similar logic already
exists in AtomicExpand.
- The current code in SelectionDAGBuilder does not use any target-hooks, it
does the same transformation for every backend that requires it
- As a result it is plain *unsound*, as it was apparently designed for ARM.
It happens to mostly work for the other targets because they are extremely
conservative, but Power for example had to switch to AtomicExpand to be
able to use lwsync safely (see r218331).
- Because it produces IR-level fences, it cannot be made sound ! This is noted
in the C++11 standard (section 29.3, page 1140):
```
Fences cannot, in general, be used to restore sequential consistency for atomic
operations with weaker ordering semantics.
```
It can also be seen by the following example (called IRIW in the litterature):
```
atomic<int> x = y = 0;
int r1, r2, r3, r4;
Thread 0:
x.store(1);
Thread 1:
y.store(1);
Thread 2:
r1 = x.load();
r2 = y.load();
Thread 3:
r3 = y.load();
r4 = x.load();
```
r1 = r3 = 1 and r2 = r4 = 0 is impossible as long as the accesses are all seq_cst.
But if they are lowered to monotonic accesses, no amount of fences can prevent it..
This patch does three things (I could cut it into parts, but then some of them
would not be tested/testable, please tell me if you would prefer that):
- it provides a default implementation for emitLeadingFence/emitTrailingFence in
terms of IR-level fences, that mimic the original logic of SelectionDAGBuilder.
As we saw above, this is unsound, but the best that can be done without knowing
the targets well (and there is a comment warning about this risk).
- it then switches Mips/Sparc/XCore to use AtomicExpand, relying on this default
implementation (that exactly replicates the logic of SelectionDAGBuilder, so no
functional change)
- it finally erase this logic from SelectionDAGBuilder as it is dead-code.
Ideally, each target would define its own override for emitLeading/TrailingFence
using target-specific fences, but I do not know the Sparc/Mips/XCore memory model
well enough to do this, and they appear to be dealing fine with the ARM-inspired
default expansion for now (probably because they are overly conservative, as
Power was). If anyone wants to compile fences more agressively on these
platforms, the long comment should make it clear why he should first override
emitLeading/TrailingFence.
Test Plan: make check-all, no functional change
Reviewers: jfb, t.p.northover
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D5474
llvm-svn: 219957
2014-10-17 04:34:57 +08:00
|
|
|
void addIRPasses() override;
|
2014-04-29 15:57:00 +08:00
|
|
|
bool addPreISel() override;
|
|
|
|
bool addInstSelector() override;
|
2014-12-12 05:26:47 +08:00
|
|
|
void addPreEmitPass() override;
|
2012-02-03 13:12:41 +08:00
|
|
|
};
|
2017-01-25 07:02:48 +08:00
|
|
|
|
|
|
|
} // end anonymous namespace
|
2012-02-03 13:12:41 +08:00
|
|
|
|
2012-02-04 10:56:59 +08:00
|
|
|
TargetPassConfig *XCoreTargetMachine::createPassConfig(PassManagerBase &PM) {
|
2017-05-31 05:36:41 +08:00
|
|
|
return new XCorePassConfig(*this, PM);
|
2012-02-03 13:12:41 +08:00
|
|
|
}
|
|
|
|
|
Erase fence insertion from SelectionDAGBuilder.cpp (NFC)
Summary:
Backends can use setInsertFencesForAtomic to signal to the middle-end that
montonic is the only memory ordering they can accept for
stores/loads/rmws/cmpxchg. The code lowering those accesses with a stronger
ordering to fences + monotonic accesses is currently living in
SelectionDAGBuilder.cpp. In this patch I propose moving this logic out of it
for several reasons:
- There is lots of redundancy to avoid: extremely similar logic already
exists in AtomicExpand.
- The current code in SelectionDAGBuilder does not use any target-hooks, it
does the same transformation for every backend that requires it
- As a result it is plain *unsound*, as it was apparently designed for ARM.
It happens to mostly work for the other targets because they are extremely
conservative, but Power for example had to switch to AtomicExpand to be
able to use lwsync safely (see r218331).
- Because it produces IR-level fences, it cannot be made sound ! This is noted
in the C++11 standard (section 29.3, page 1140):
```
Fences cannot, in general, be used to restore sequential consistency for atomic
operations with weaker ordering semantics.
```
It can also be seen by the following example (called IRIW in the litterature):
```
atomic<int> x = y = 0;
int r1, r2, r3, r4;
Thread 0:
x.store(1);
Thread 1:
y.store(1);
Thread 2:
r1 = x.load();
r2 = y.load();
Thread 3:
r3 = y.load();
r4 = x.load();
```
r1 = r3 = 1 and r2 = r4 = 0 is impossible as long as the accesses are all seq_cst.
But if they are lowered to monotonic accesses, no amount of fences can prevent it..
This patch does three things (I could cut it into parts, but then some of them
would not be tested/testable, please tell me if you would prefer that):
- it provides a default implementation for emitLeadingFence/emitTrailingFence in
terms of IR-level fences, that mimic the original logic of SelectionDAGBuilder.
As we saw above, this is unsound, but the best that can be done without knowing
the targets well (and there is a comment warning about this risk).
- it then switches Mips/Sparc/XCore to use AtomicExpand, relying on this default
implementation (that exactly replicates the logic of SelectionDAGBuilder, so no
functional change)
- it finally erase this logic from SelectionDAGBuilder as it is dead-code.
Ideally, each target would define its own override for emitLeading/TrailingFence
using target-specific fences, but I do not know the Sparc/Mips/XCore memory model
well enough to do this, and they appear to be dealing fine with the ARM-inspired
default expansion for now (probably because they are overly conservative, as
Power was). If anyone wants to compile fences more agressively on these
platforms, the long comment should make it clear why he should first override
emitLeading/TrailingFence.
Test Plan: make check-all, no functional change
Reviewers: jfb, t.p.northover
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D5474
llvm-svn: 219957
2014-10-17 04:34:57 +08:00
|
|
|
void XCorePassConfig::addIRPasses() {
|
2017-05-19 01:21:13 +08:00
|
|
|
addPass(createAtomicExpandPass());
|
Erase fence insertion from SelectionDAGBuilder.cpp (NFC)
Summary:
Backends can use setInsertFencesForAtomic to signal to the middle-end that
montonic is the only memory ordering they can accept for
stores/loads/rmws/cmpxchg. The code lowering those accesses with a stronger
ordering to fences + monotonic accesses is currently living in
SelectionDAGBuilder.cpp. In this patch I propose moving this logic out of it
for several reasons:
- There is lots of redundancy to avoid: extremely similar logic already
exists in AtomicExpand.
- The current code in SelectionDAGBuilder does not use any target-hooks, it
does the same transformation for every backend that requires it
- As a result it is plain *unsound*, as it was apparently designed for ARM.
It happens to mostly work for the other targets because they are extremely
conservative, but Power for example had to switch to AtomicExpand to be
able to use lwsync safely (see r218331).
- Because it produces IR-level fences, it cannot be made sound ! This is noted
in the C++11 standard (section 29.3, page 1140):
```
Fences cannot, in general, be used to restore sequential consistency for atomic
operations with weaker ordering semantics.
```
It can also be seen by the following example (called IRIW in the litterature):
```
atomic<int> x = y = 0;
int r1, r2, r3, r4;
Thread 0:
x.store(1);
Thread 1:
y.store(1);
Thread 2:
r1 = x.load();
r2 = y.load();
Thread 3:
r3 = y.load();
r4 = x.load();
```
r1 = r3 = 1 and r2 = r4 = 0 is impossible as long as the accesses are all seq_cst.
But if they are lowered to monotonic accesses, no amount of fences can prevent it..
This patch does three things (I could cut it into parts, but then some of them
would not be tested/testable, please tell me if you would prefer that):
- it provides a default implementation for emitLeadingFence/emitTrailingFence in
terms of IR-level fences, that mimic the original logic of SelectionDAGBuilder.
As we saw above, this is unsound, but the best that can be done without knowing
the targets well (and there is a comment warning about this risk).
- it then switches Mips/Sparc/XCore to use AtomicExpand, relying on this default
implementation (that exactly replicates the logic of SelectionDAGBuilder, so no
functional change)
- it finally erase this logic from SelectionDAGBuilder as it is dead-code.
Ideally, each target would define its own override for emitLeading/TrailingFence
using target-specific fences, but I do not know the Sparc/Mips/XCore memory model
well enough to do this, and they appear to be dealing fine with the ARM-inspired
default expansion for now (probably because they are overly conservative, as
Power was). If anyone wants to compile fences more agressively on these
platforms, the long comment should make it clear why he should first override
emitLeading/TrailingFence.
Test Plan: make check-all, no functional change
Reviewers: jfb, t.p.northover
Subscribers: aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D5474
llvm-svn: 219957
2014-10-17 04:34:57 +08:00
|
|
|
|
|
|
|
TargetPassConfig::addIRPasses();
|
|
|
|
}
|
|
|
|
|
2013-05-05 01:01:55 +08:00
|
|
|
bool XCorePassConfig::addPreISel() {
|
|
|
|
addPass(createXCoreLowerThreadLocalPass());
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2012-02-03 13:12:41 +08:00
|
|
|
bool XCorePassConfig::addInstSelector() {
|
2012-07-03 03:48:31 +08:00
|
|
|
addPass(createXCoreISelDag(getXCoreTargetMachine(), getOptLevel()));
|
2008-11-07 18:59:00 +08:00
|
|
|
return false;
|
|
|
|
}
|
2009-08-15 20:53:15 +08:00
|
|
|
|
2014-12-12 05:26:47 +08:00
|
|
|
void XCorePassConfig::addPreEmitPass() {
|
|
|
|
addPass(createXCoreFrameToArgsOffsetEliminationPass(), false);
|
2014-01-06 22:21:00 +08:00
|
|
|
}
|
|
|
|
|
2009-08-15 20:53:15 +08:00
|
|
|
// Force static initialization.
|
|
|
|
extern "C" void LLVMInitializeXCoreTarget() {
|
2016-10-12 02:22:41 +08:00
|
|
|
RegisterTargetMachine<XCoreTargetMachine> X(getTheXCoreTarget());
|
2009-08-15 20:53:15 +08:00
|
|
|
}
|
2013-09-18 20:43:35 +08:00
|
|
|
|
(Re-landing) Expose a TargetMachine::getTargetTransformInfo function
Re-land r321234. It had to be reverted because it broke the shared
library build. The shared library build broke because there was a
missing LLVMBuild dependency from lib/Passes (which calls
TargetMachine::getTargetIRAnalysis) to lib/Target. As far as I can
tell, this problem was always there but was somehow masked
before (perhaps because TargetMachine::getTargetIRAnalysis was a
virtual function).
Original commit message:
This makes the TargetMachine interface a bit simpler. We still need
the std::function in TargetIRAnalysis to avoid having to add a
dependency from Analysis to Target.
See discussion:
http://lists.llvm.org/pipermail/llvm-dev/2017-December/119749.html
I avoided adding all of the backend owners to this review since the
change is simple, but let me know if you feel differently about this.
Reviewers: echristo, MatzeB, hfinkel
Reviewed By: hfinkel
Subscribers: jholewinski, jfb, arsenm, dschuff, mcrosier, sdardis, nemanjai, nhaehnle, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, llvm-commits
Differential Revision: https://reviews.llvm.org/D41464
llvm-svn: 321375
2017-12-23 02:21:59 +08:00
|
|
|
TargetTransformInfo
|
|
|
|
XCoreTargetMachine::getTargetTransformInfo(const Function &F) {
|
|
|
|
return TargetTransformInfo(XCoreTTIImpl(this, F));
|
2013-09-18 20:43:35 +08:00
|
|
|
}
|