2005-10-16 13:39:50 +08:00
|
|
|
//===-- PPCTargetMachine.cpp - Define TargetMachine for PowerPC -----------===//
|
2005-04-22 07:30:14 +08:00
|
|
|
//
|
2004-06-22 00:55:25 +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-04-22 07:30:14 +08:00
|
|
|
//
|
2004-06-22 00:55:25 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2005-04-22 07:30:14 +08:00
|
|
|
//
|
2005-08-16 07:47:04 +08:00
|
|
|
// Top-level implementation for the PowerPC target.
|
2004-06-22 00:55:25 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2005-10-15 07:59:06 +08:00
|
|
|
#include "PPCTargetMachine.h"
|
2012-03-18 02:46:09 +08:00
|
|
|
#include "PPC.h"
|
2012-02-03 13:12:41 +08:00
|
|
|
#include "llvm/CodeGen/Passes.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/MC/MCStreamer.h"
|
|
|
|
#include "llvm/PassManager.h"
|
2012-06-08 23:38:21 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2009-07-15 04:18:05 +08:00
|
|
|
#include "llvm/Support/FormattedStream.h"
|
2011-08-25 02:08:43 +08:00
|
|
|
#include "llvm/Support/TargetRegistry.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/Target/TargetOptions.h"
|
2004-06-22 00:55:25 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2012-06-08 23:38:21 +08:00
|
|
|
static cl::
|
2012-06-09 03:19:53 +08:00
|
|
|
opt<bool> DisableCTRLoops("disable-ppc-ctrloops", cl::Hidden,
|
|
|
|
cl::desc("Disable CTR loops for PPC"));
|
2012-06-08 23:38:21 +08:00
|
|
|
|
2009-07-25 14:49:55 +08:00
|
|
|
extern "C" void LLVMInitializePowerPCTarget() {
|
|
|
|
// Register the targets
|
2012-02-03 13:12:30 +08:00
|
|
|
RegisterTargetMachine<PPC32TargetMachine> A(ThePPC32Target);
|
2009-07-25 14:49:55 +08:00
|
|
|
RegisterTargetMachine<PPC64TargetMachine> B(ThePPC64Target);
|
2013-07-26 09:35:43 +08:00
|
|
|
RegisterTargetMachine<PPC64TargetMachine> C(ThePPC64LETarget);
|
2009-07-25 14:49:55 +08:00
|
|
|
}
|
2009-06-17 04:12:29 +08:00
|
|
|
|
2013-12-11 08:09:06 +08:00
|
|
|
/// Return the datalayout string of a subtarget.
|
|
|
|
static std::string getDataLayoutString(const PPCSubtarget &ST) {
|
2013-12-17 23:29:48 +08:00
|
|
|
const Triple &T = ST.getTargetTriple();
|
|
|
|
|
2013-12-12 16:00:34 +08:00
|
|
|
// PPC is big endian.
|
2013-12-11 08:09:06 +08:00
|
|
|
std::string Ret = "E";
|
|
|
|
|
2014-01-04 03:21:54 +08:00
|
|
|
Ret += DataLayout::getManglingComponent(T);
|
|
|
|
|
2013-12-17 23:29:48 +08:00
|
|
|
// PPC32 has 32 bit pointers. The PS3 (OS Lv2) is a PPC64 machine with 32 bit
|
|
|
|
// pointers.
|
|
|
|
if (!ST.isPPC64() || T.getOS() == Triple::Lv2)
|
2013-12-11 08:09:06 +08:00
|
|
|
Ret += "-p:32:32";
|
|
|
|
|
|
|
|
// Note, the alignment values for f64 and i64 on ppc64 in Darwin
|
|
|
|
// documentation are wrong; these are correct (i.e. "what gcc does").
|
2013-12-18 22:35:37 +08:00
|
|
|
if (ST.isPPC64() || ST.isSVR4ABI())
|
|
|
|
Ret += "-i64:64";
|
2013-12-18 23:06:25 +08:00
|
|
|
else
|
|
|
|
Ret += "-f64:32:64";
|
2013-12-11 08:09:06 +08:00
|
|
|
|
2013-12-12 16:00:34 +08:00
|
|
|
// PPC64 has 32 and 64 bit registers, PPC32 has only 32 bit ones.
|
2013-12-11 08:09:06 +08:00
|
|
|
if (ST.isPPC64())
|
|
|
|
Ret += "-n32:64";
|
|
|
|
else
|
|
|
|
Ret += "-n32";
|
|
|
|
|
|
|
|
return Ret;
|
|
|
|
}
|
|
|
|
|
2011-07-19 14:37:02 +08:00
|
|
|
PPCTargetMachine::PPCTargetMachine(const Target &T, StringRef TT,
|
|
|
|
StringRef CPU, StringRef FS,
|
2011-12-03 06:16:29 +08:00
|
|
|
const TargetOptions &Options,
|
2011-07-20 15:51:56 +08:00
|
|
|
Reloc::Model RM, CodeModel::Model CM,
|
2011-11-16 16:38:26 +08:00
|
|
|
CodeGenOpt::Level OL,
|
2011-07-20 15:51:56 +08:00
|
|
|
bool is64Bit)
|
2011-12-03 06:16:29 +08:00
|
|
|
: LLVMTargetMachine(T, TT, CPU, FS, Options, RM, CM, OL),
|
Add CR-bit tracking to the PowerPC backend for i1 values
This change enables tracking i1 values in the PowerPC backend using the
condition register bits. These bits can be treated on PowerPC as separate
registers; individual bit operations (and, or, xor, etc.) are supported.
Tracking booleans in CR bits has several advantages:
- Reduction in register pressure (because we no longer need GPRs to store
boolean values).
- Logical operations on booleans can be handled more efficiently; we used to
have to move all results from comparisons into GPRs, perform promoted
logical operations in GPRs, and then move the result back into condition
register bits to be used by conditional branches. This can be very
inefficient, because the throughput of these CR <-> GPR moves have high
latency and low throughput (especially when other associated instructions
are accounted for).
- On the POWER7 and similar cores, we can increase total throughput by using
the CR bits. CR bit operations have a dedicated functional unit.
Most of this is more-or-less mechanical: Adjustments were needed in the
calling-convention code, support was added for spilling/restoring individual
condition-register bits, and conditional branch instruction definitions taking
specific CR bits were added (plus patterns and code for generating bit-level
operations).
This is enabled by default when running at -O2 and higher. For -O0 and -O1,
where the ability to debug is more important, this feature is disabled by
default. Individual CR bits do not have assigned DWARF register numbers,
and storing values in CR bits makes them invisible to the debugger.
It is critical, however, that we don't move i1 values that have been promoted
to larger values (such as those passed as function arguments) into bit
registers only to quickly turn around and move the values back into GPRs (such
as happens when values are returned by functions). A pair of target-specific
DAG combines are added to remove the trunc/extends in:
trunc(binary-ops(binary-ops(zext(x), zext(y)), ...)
and:
zext(binary-ops(binary-ops(trunc(x), trunc(y)), ...)
In short, we only want to use CR bits where some of the i1 values come from
comparisons or are used by conditional branches or selects. To put it another
way, if we can do the entire i1 computation in GPRs, then we probably should
(on the POWER7, the GPR-operation throughput is higher, and for all cores, the
CR <-> GPR moves are expensive).
POWER7 test-suite performance results (from 10 runs in each configuration):
SingleSource/Benchmarks/Misc/mandel-2: 35% speedup
MultiSource/Benchmarks/Prolangs-C++/city/city: 21% speedup
MultiSource/Benchmarks/MiBench/automotive-susan: 23% speedup
SingleSource/Benchmarks/CoyoteBench/huffbench: 13% speedup
SingleSource/Benchmarks/Misc-C++/Large/sphereflake: 13% speedup
SingleSource/Benchmarks/Misc-C++/mandel-text: 10% speedup
SingleSource/Benchmarks/Misc-C++-EH/spirit: 10% slowdown
MultiSource/Applications/lemon/lemon: 8% slowdown
llvm-svn: 202451
2014-02-28 08:27:01 +08:00
|
|
|
Subtarget(TT, CPU, FS, is64Bit, OL),
|
2013-12-11 08:09:06 +08:00
|
|
|
DL(getDataLayoutString(Subtarget)), InstrInfo(*this),
|
2011-01-10 20:39:04 +08:00
|
|
|
FrameLowering(Subtarget), JITInfo(*this, is64Bit),
|
2010-05-12 01:31:57 +08:00
|
|
|
TLInfo(*this), TSInfo(*this),
|
Switch TargetTransformInfo from an immutable analysis pass that requires
a TargetMachine to construct (and thus isn't always available), to an
analysis group that supports layered implementations much like
AliasAnalysis does. This is a pretty massive change, with a few parts
that I was unable to easily separate (sorry), so I'll walk through it.
The first step of this conversion was to make TargetTransformInfo an
analysis group, and to sink the nonce implementations in
ScalarTargetTransformInfo and VectorTargetTranformInfo into
a NoTargetTransformInfo pass. This allows other passes to add a hard
requirement on TTI, and assume they will always get at least on
implementation.
The TargetTransformInfo analysis group leverages the delegation chaining
trick that AliasAnalysis uses, where the base class for the analysis
group delegates to the previous analysis *pass*, allowing all but tho
NoFoo analysis passes to only implement the parts of the interfaces they
support. It also introduces a new trick where each pass in the group
retains a pointer to the top-most pass that has been initialized. This
allows passes to implement one API in terms of another API and benefit
when some other pass above them in the stack has more precise results
for the second API.
The second step of this conversion is to create a pass that implements
the TargetTransformInfo analysis using the target-independent
abstractions in the code generator. This replaces the
ScalarTargetTransformImpl and VectorTargetTransformImpl classes in
lib/Target with a single pass in lib/CodeGen called
BasicTargetTransformInfo. This class actually provides most of the TTI
functionality, basing it upon the TargetLowering abstraction and other
information in the target independent code generator.
The third step of the conversion adds support to all TargetMachines to
register custom analysis passes. This allows building those passes with
access to TargetLowering or other target-specific classes, and it also
allows each target to customize the set of analysis passes desired in
the pass manager. The baseline LLVMTargetMachine implements this
interface to add the BasicTTI pass to the pass manager, and all of the
tools that want to support target-aware TTI passes call this routine on
whatever target machine they end up with to add the appropriate passes.
The fourth step of the conversion created target-specific TTI analysis
passes for the X86 and ARM backends. These passes contain the custom
logic that was previously in their extensions of the
ScalarTargetTransformInfo and VectorTargetTransformInfo interfaces.
I separated them into their own file, as now all of the interface bits
are private and they just expose a function to create the pass itself.
Then I extended these target machines to set up a custom set of analysis
passes, first adding BasicTTI as a fallback, and then adding their
customized TTI implementations.
The fourth step required logic that was shared between the target
independent layer and the specific targets to move to a different
interface, as they no longer derive from each other. As a consequence,
a helper functions were added to TargetLowering representing the common
logic needed both in the target implementation and the codegen
implementation of the TTI pass. While technically this is the only
change that could have been committed separately, it would have been
a nightmare to extract.
The final step of the conversion was just to delete all the old
boilerplate. This got rid of the ScalarTargetTransformInfo and
VectorTargetTransformInfo classes, all of the support in all of the
targets for producing instances of them, and all of the support in the
tools for manually constructing a pass based around them.
Now that TTI is a relatively normal analysis group, two things become
straightforward. First, we can sink it into lib/Analysis which is a more
natural layer for it to live. Second, clients of this interface can
depend on it *always* being available which will simplify their code and
behavior. These (and other) simplifications will follow in subsequent
commits, this one is clearly big enough.
Finally, I'm very aware that much of the comments and documentation
needs to be updated. As soon as I had this working, and plausibly well
commented, I wanted to get it committed and in front of the build bots.
I'll be doing a few passes over documentation later if it sticks.
Commits to update DragonEgg and Clang will be made presently.
llvm-svn: 171681
2013-01-07 09:37:14 +08:00
|
|
|
InstrItins(Subtarget.getInstrItineraryData()) {
|
2012-04-03 03:09:04 +08:00
|
|
|
|
|
|
|
// The binutils for the BG/P are too old for CFI.
|
|
|
|
if (Subtarget.isBGP())
|
|
|
|
setMCUseCFI(false);
|
2013-05-13 09:16:13 +08:00
|
|
|
initAsmInfo();
|
2005-10-16 13:39:50 +08:00
|
|
|
}
|
|
|
|
|
2011-12-20 10:50:00 +08:00
|
|
|
void PPC32TargetMachine::anchor() { }
|
|
|
|
|
2012-02-03 13:12:30 +08:00
|
|
|
PPC32TargetMachine::PPC32TargetMachine(const Target &T, StringRef TT,
|
2011-07-20 15:51:56 +08:00
|
|
|
StringRef CPU, StringRef FS,
|
2011-12-03 06:16:29 +08:00
|
|
|
const TargetOptions &Options,
|
2011-11-16 16:38:26 +08:00
|
|
|
Reloc::Model RM, CodeModel::Model CM,
|
|
|
|
CodeGenOpt::Level OL)
|
2011-12-03 06:16:29 +08:00
|
|
|
: PPCTargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, false) {
|
2006-06-16 09:37:27 +08:00
|
|
|
}
|
|
|
|
|
2011-12-20 10:50:00 +08:00
|
|
|
void PPC64TargetMachine::anchor() { }
|
2006-06-16 09:37:27 +08:00
|
|
|
|
2012-02-03 13:12:30 +08:00
|
|
|
PPC64TargetMachine::PPC64TargetMachine(const Target &T, StringRef TT,
|
2011-07-20 15:51:56 +08:00
|
|
|
StringRef CPU, StringRef FS,
|
2011-12-03 06:16:29 +08:00
|
|
|
const TargetOptions &Options,
|
2011-11-16 16:38:26 +08:00
|
|
|
Reloc::Model RM, CodeModel::Model CM,
|
|
|
|
CodeGenOpt::Level OL)
|
2011-12-03 06:16:29 +08:00
|
|
|
: PPCTargetMachine(T, TT, CPU, FS, Options, RM, CM, OL, true) {
|
2006-06-16 09:37:27 +08:00
|
|
|
}
|
|
|
|
|
2004-08-11 15:40:04 +08:00
|
|
|
|
2006-09-04 12:14:57 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Pass Pipeline Configuration
|
|
|
|
//===----------------------------------------------------------------------===//
|
2004-08-11 15:40:04 +08:00
|
|
|
|
2012-02-03 13:12:41 +08:00
|
|
|
namespace {
|
|
|
|
/// PPC Code Generator Pass Configuration Options.
|
|
|
|
class PPCPassConfig : public TargetPassConfig {
|
|
|
|
public:
|
2012-02-04 10:56:59 +08:00
|
|
|
PPCPassConfig(PPCTargetMachine *TM, PassManagerBase &PM)
|
|
|
|
: TargetPassConfig(TM, PM) {}
|
2012-02-03 13:12:41 +08:00
|
|
|
|
|
|
|
PPCTargetMachine &getPPCTargetMachine() const {
|
|
|
|
return getTM<PPCTargetMachine>();
|
|
|
|
}
|
|
|
|
|
2013-04-06 07:29:01 +08:00
|
|
|
const PPCSubtarget &getPPCSubtarget() const {
|
|
|
|
return *getPPCTargetMachine().getSubtargetImpl();
|
|
|
|
}
|
|
|
|
|
Implement PPC counter loops as a late IR-level pass
The old PPCCTRLoops pass, like the Hexagon pass version from which it was
derived, could only handle some simple loops in canonical form. We cannot
directly adapt the new Hexagon hardware loops pass, however, because the
Hexagon pass contains a fundamental assumption that non-constant-trip-count
loops will contain a guard, and this is not always true (the result being that
incorrect negative counts can be generated). With this commit, we replace the
pass with a late IR-level pass which makes use of SE to calculate the
backedge-taken counts and safely generate the loop-count expressions (including
any necessary max() parts). This IR level pass inserts custom intrinsics that
are lowered into the desired decrement-and-branch instructions.
The most fragile part of this new implementation is that interfering uses of
the counter register must be detected on the IR level (and, on PPC, this also
includes any indirect branches in addition to function calls). Also, to make
all of this work, we need a variant of the mtctr instruction that is marked
as having side effects. Without this, machine-code level CSE, DCE, etc.
illegally transform the resulting code. Hopefully, this can be improved
in the future.
This new pass is smaller than the original (and much smaller than the new
Hexagon hardware loops pass), and can handle many additional cases correctly.
In addition, the preheader-creation code has been copied from LoopSimplify, and
after we decide on where it belongs, this code will be refactored so that it
can be explicitly shared (making this implementation even smaller).
The new test-case files ctrloop-{le,lt,ne}.ll have been adapted from tests for
the new Hexagon pass. There are a few classes of loops that this pass does not
transform (noted by FIXMEs in the files), but these deficiencies can be
addressed within the SE infrastructure (thus helping many other passes as well).
llvm-svn: 181927
2013-05-16 05:37:41 +08:00
|
|
|
virtual bool addPreISel();
|
2013-04-06 07:29:01 +08:00
|
|
|
virtual bool addILPOpts();
|
2012-02-03 13:12:41 +08:00
|
|
|
virtual bool addInstSelector();
|
2013-04-10 06:58:37 +08:00
|
|
|
virtual bool addPreSched2();
|
2012-02-03 13:12:41 +08:00
|
|
|
virtual bool addPreEmitPass();
|
|
|
|
};
|
|
|
|
} // namespace
|
|
|
|
|
2012-02-04 10:56:59 +08:00
|
|
|
TargetPassConfig *PPCTargetMachine::createPassConfig(PassManagerBase &PM) {
|
2012-06-09 11:14:50 +08:00
|
|
|
return new PPCPassConfig(this, PM);
|
2012-02-03 13:12:41 +08:00
|
|
|
}
|
|
|
|
|
Implement PPC counter loops as a late IR-level pass
The old PPCCTRLoops pass, like the Hexagon pass version from which it was
derived, could only handle some simple loops in canonical form. We cannot
directly adapt the new Hexagon hardware loops pass, however, because the
Hexagon pass contains a fundamental assumption that non-constant-trip-count
loops will contain a guard, and this is not always true (the result being that
incorrect negative counts can be generated). With this commit, we replace the
pass with a late IR-level pass which makes use of SE to calculate the
backedge-taken counts and safely generate the loop-count expressions (including
any necessary max() parts). This IR level pass inserts custom intrinsics that
are lowered into the desired decrement-and-branch instructions.
The most fragile part of this new implementation is that interfering uses of
the counter register must be detected on the IR level (and, on PPC, this also
includes any indirect branches in addition to function calls). Also, to make
all of this work, we need a variant of the mtctr instruction that is marked
as having side effects. Without this, machine-code level CSE, DCE, etc.
illegally transform the resulting code. Hopefully, this can be improved
in the future.
This new pass is smaller than the original (and much smaller than the new
Hexagon hardware loops pass), and can handle many additional cases correctly.
In addition, the preheader-creation code has been copied from LoopSimplify, and
after we decide on where it belongs, this code will be refactored so that it
can be explicitly shared (making this implementation even smaller).
The new test-case files ctrloop-{le,lt,ne}.ll have been adapted from tests for
the new Hexagon pass. There are a few classes of loops that this pass does not
transform (noted by FIXMEs in the files), but these deficiencies can be
addressed within the SE infrastructure (thus helping many other passes as well).
llvm-svn: 181927
2013-05-16 05:37:41 +08:00
|
|
|
bool PPCPassConfig::addPreISel() {
|
2012-06-09 03:19:53 +08:00
|
|
|
if (!DisableCTRLoops && getOptLevel() != CodeGenOpt::None)
|
Implement PPC counter loops as a late IR-level pass
The old PPCCTRLoops pass, like the Hexagon pass version from which it was
derived, could only handle some simple loops in canonical form. We cannot
directly adapt the new Hexagon hardware loops pass, however, because the
Hexagon pass contains a fundamental assumption that non-constant-trip-count
loops will contain a guard, and this is not always true (the result being that
incorrect negative counts can be generated). With this commit, we replace the
pass with a late IR-level pass which makes use of SE to calculate the
backedge-taken counts and safely generate the loop-count expressions (including
any necessary max() parts). This IR level pass inserts custom intrinsics that
are lowered into the desired decrement-and-branch instructions.
The most fragile part of this new implementation is that interfering uses of
the counter register must be detected on the IR level (and, on PPC, this also
includes any indirect branches in addition to function calls). Also, to make
all of this work, we need a variant of the mtctr instruction that is marked
as having side effects. Without this, machine-code level CSE, DCE, etc.
illegally transform the resulting code. Hopefully, this can be improved
in the future.
This new pass is smaller than the original (and much smaller than the new
Hexagon hardware loops pass), and can handle many additional cases correctly.
In addition, the preheader-creation code has been copied from LoopSimplify, and
after we decide on where it belongs, this code will be refactored so that it
can be explicitly shared (making this implementation even smaller).
The new test-case files ctrloop-{le,lt,ne}.ll have been adapted from tests for
the new Hexagon pass. There are a few classes of loops that this pass does not
transform (noted by FIXMEs in the files), but these deficiencies can be
addressed within the SE infrastructure (thus helping many other passes as well).
llvm-svn: 181927
2013-05-16 05:37:41 +08:00
|
|
|
addPass(createPPCCTRLoops(getPPCTargetMachine()));
|
2012-06-08 23:38:21 +08:00
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-04-06 07:29:01 +08:00
|
|
|
bool PPCPassConfig::addILPOpts() {
|
|
|
|
if (getPPCSubtarget().hasISEL()) {
|
|
|
|
addPass(&EarlyIfConverterID);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2012-02-03 13:12:41 +08:00
|
|
|
bool PPCPassConfig::addInstSelector() {
|
2005-08-18 03:33:30 +08:00
|
|
|
// Install an instruction selector.
|
2012-07-03 03:48:31 +08:00
|
|
|
addPass(createPPCISelDag(getPPCTargetMachine()));
|
Add a PPCCTRLoops verification pass
When asserts are enabled, this adds a verification pass for PPC counter-loop
formation. Unfortunately, without sacrificing code quality, there is no better
way of forming counter-based loops except at the (late) IR level. This means
that we need to recognize, at the IR level, anything which might turn into a
function call (or indirect branch). Because this is currently a finite set of
things, and because SelectionDAG lowering is basic-block local, this can be
done. Nevertheless, it is fragile, and failure results in a miscompile. This
verification pass checks that all (reachable) counter-based branches are
dominated by a loop mtctr instruction, and that no instructions in between
clobber the counter register. If these conditions are not satisfied, then an
ICE will be triggered.
In short, this is to help us sleep better at night.
llvm-svn: 182295
2013-05-21 00:08:17 +08:00
|
|
|
|
|
|
|
#ifndef NDEBUG
|
|
|
|
if (!DisableCTRLoops && getOptLevel() != CodeGenOpt::None)
|
|
|
|
addPass(createPPCCTRLoopsVerify());
|
|
|
|
#endif
|
|
|
|
|
2006-09-04 12:14:57 +08:00
|
|
|
return false;
|
|
|
|
}
|
2004-08-11 15:40:04 +08:00
|
|
|
|
2013-04-10 06:58:37 +08:00
|
|
|
bool PPCPassConfig::addPreSched2() {
|
|
|
|
if (getOptLevel() != CodeGenOpt::None)
|
|
|
|
addPass(&IfConverterID);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2012-02-03 13:12:41 +08:00
|
|
|
bool PPCPassConfig::addPreEmitPass() {
|
2013-04-09 00:24:03 +08:00
|
|
|
if (getOptLevel() != CodeGenOpt::None)
|
|
|
|
addPass(createPPCEarlyReturnPass());
|
2006-09-04 12:14:57 +08:00
|
|
|
// Must run branch selection immediately preceding the asm printer.
|
2012-07-03 03:48:31 +08:00
|
|
|
addPass(createPPCBranchSelectionPass());
|
2004-08-11 15:40:04 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2009-05-31 04:51:52 +08:00
|
|
|
bool PPCTargetMachine::addCodeEmitter(PassManagerBase &PM,
|
2009-07-16 06:33:19 +08:00
|
|
|
JITCodeEmitter &JCE) {
|
2009-05-31 04:51:52 +08:00
|
|
|
// Inform the subtarget that we are in JIT mode. FIXME: does this break macho
|
|
|
|
// writing?
|
|
|
|
Subtarget.SetJITMode();
|
2012-02-03 13:12:30 +08:00
|
|
|
|
2009-05-31 04:51:52 +08:00
|
|
|
// Machine code emitter pass for PowerPC.
|
|
|
|
PM.add(createPPCJITCodeEmitterPass(*this, JCE));
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
2013-01-26 07:05:59 +08:00
|
|
|
|
|
|
|
void PPCTargetMachine::addAnalysisPasses(PassManagerBase &PM) {
|
|
|
|
// Add first the target-independent BasicTTI pass, then our PPC pass. This
|
|
|
|
// allows the PPC pass to delegate to the target independent layer when
|
|
|
|
// appropriate.
|
2013-06-20 04:51:24 +08:00
|
|
|
PM.add(createBasicTargetTransformInfoPass(this));
|
2013-01-26 07:05:59 +08:00
|
|
|
PM.add(createPPCTargetTransformInfoPass(this));
|
|
|
|
}
|
|
|
|
|