2012-02-18 20:03:15 +08:00
|
|
|
//===-- PowerPCSubtarget.cpp - PPC Subtarget Information ------------------===//
|
2005-08-04 15:12:09 +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-08-04 15:12:09 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2011-07-02 05:01:15 +08:00
|
|
|
// This file implements the PPC specific subclass of TargetSubtargetInfo.
|
2005-08-04 15:12:09 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2005-10-15 07:51:18 +08:00
|
|
|
#include "PPCSubtarget.h"
|
|
|
|
#include "PPC.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "PPCRegisterInfo.h"
|
2015-01-27 03:03:15 +08:00
|
|
|
#include "PPCTargetMachine.h"
|
2013-07-16 06:29:40 +08:00
|
|
|
#include "llvm/CodeGen/MachineFunction.h"
|
2013-09-12 07:05:25 +08:00
|
|
|
#include "llvm/CodeGen/MachineScheduler.h"
|
2013-07-16 06:29:40 +08:00
|
|
|
#include "llvm/IR/Attributes.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
2014-01-07 19:48:04 +08:00
|
|
|
#include "llvm/IR/GlobalValue.h"
|
2015-01-09 10:03:11 +08:00
|
|
|
#include "llvm/Support/CommandLine.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/TargetMachine.h"
|
2009-01-06 01:59:02 +08:00
|
|
|
#include <cstdlib>
|
2011-07-02 04:45:01 +08:00
|
|
|
|
2014-04-22 10:03:14 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2014-04-22 06:55:11 +08:00
|
|
|
#define DEBUG_TYPE "ppc-subtarget"
|
|
|
|
|
2011-07-02 04:45:01 +08:00
|
|
|
#define GET_SUBTARGETINFO_TARGET_DESC
|
2011-07-08 09:53:10 +08:00
|
|
|
#define GET_SUBTARGETINFO_CTOR
|
2011-07-02 06:36:09 +08:00
|
|
|
#include "PPCGenSubtargetInfo.inc"
|
2011-07-02 04:45:01 +08:00
|
|
|
|
2015-01-09 10:03:11 +08:00
|
|
|
static cl::opt<bool> UseSubRegLiveness("ppc-track-subreg-liveness",
|
|
|
|
cl::desc("Enable subregister liveness tracking for PPC"), cl::Hidden);
|
|
|
|
|
[PowerPC] Add support for the QPX vector instruction set
This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).
I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).
The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.
llvm-svn: 230413
2015-02-25 09:06:45 +08:00
|
|
|
static cl::opt<bool> QPXStackUnaligned("qpx-stack-unaligned",
|
|
|
|
cl::desc("Even when QPX is enabled the stack is not 32-byte aligned"),
|
|
|
|
cl::Hidden);
|
|
|
|
|
2014-06-13 04:54:11 +08:00
|
|
|
PPCSubtarget &PPCSubtarget::initializeSubtargetDependencies(StringRef CPU,
|
|
|
|
StringRef FS) {
|
|
|
|
initializeEnvironment();
|
2014-09-04 04:36:31 +08:00
|
|
|
initSubtargetFeatures(CPU, FS);
|
2014-06-13 04:54:11 +08:00
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
2015-06-10 20:11:26 +08:00
|
|
|
PPCSubtarget::PPCSubtarget(const Triple &TT, const std::string &CPU,
|
2014-10-02 05:36:28 +08:00
|
|
|
const std::string &FS, const PPCTargetMachine &TM)
|
2015-09-16 00:17:27 +08:00
|
|
|
: PPCGenSubtargetInfo(TT, CPU, FS), TargetTriple(TT),
|
2014-08-09 12:38:56 +08:00
|
|
|
IsPPC64(TargetTriple.getArch() == Triple::ppc64 ||
|
|
|
|
TargetTriple.getArch() == Triple::ppc64le),
|
2015-02-17 14:45:15 +08:00
|
|
|
TM(TM), FrameLowering(initializeSubtargetDependencies(CPU, FS)),
|
2015-07-09 10:10:08 +08:00
|
|
|
InstrInfo(*this), TLInfo(TM, *this) {}
|
2014-08-08 06:02:54 +08:00
|
|
|
|
2013-07-16 06:29:40 +08:00
|
|
|
void PPCSubtarget::initializeEnvironment() {
|
|
|
|
StackAlignment = 16;
|
|
|
|
DarwinDirective = PPC::DIR_NONE;
|
|
|
|
HasMFOCRF = false;
|
|
|
|
Has64BitSupport = false;
|
|
|
|
Use64BitRegs = false;
|
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
|
|
|
UseCRBits = false;
|
[PowerPC] Refactor soft-float support, and enable PPC64 soft float
This change enables soft-float for PowerPC64, and also makes soft-float disable
all vector instruction sets for both 32-bit and 64-bit modes. This latter part
is necessary because the PPC backend canonicalizes many Altivec vector types to
floating-point types, and so soft-float breaks scalarization support for many
operations. Both for embedded targets and for operating-system kernels desiring
soft-float support, it seems reasonable that disabling hardware floating-point
also disables vector instructions (embedded targets without hardware floating
point support are unlikely to have Altivec, etc. and operating system kernels
desiring not to use floating-point registers to lower syscall cost are unlikely
to want to use vector registers either). If someone needs this to work, we'll
need to change the fact that we promote many Altivec operations to act on
v4f32. To make it possible to disable Altivec when soft-float is enabled,
hardware floating-point support needs to be expressed as a positive feature,
like the others, and not a negative feature, because target features cannot
have dependencies on the disabling of some other feature. So +soft-float has
now become -hard-float.
Fixes PR26970.
llvm-svn: 283060
2016-10-02 10:10:20 +08:00
|
|
|
HasHardFloat = false;
|
2013-07-16 06:29:40 +08:00
|
|
|
HasAltivec = false;
|
2014-08-07 20:18:21 +08:00
|
|
|
HasSPE = false;
|
2013-07-16 06:29:40 +08:00
|
|
|
HasQPX = false;
|
[PowerPC] Initial support for the VSX instruction set
VSX is an ISA extension supported on the POWER7 and later cores that enhances
floating-point vector and scalar capabilities. Among other things, this adds
<2 x double> support and generally helps to reduce register pressure.
The interesting part of this ISA feature is the register configuration: there
are 64 new 128-bit vector registers, the 32 of which are super-registers of the
existing 32 scalar floating-point registers, and the second 32 of which overlap
with the 32 Altivec vector registers. This makes things like vector insertion
and extraction tricky: this can be free but only if we force a restriction to
the right register subclass when needed. A new "minipass" PPCVSXCopy takes care
of this (although it could do a more-optimal job of it; see the comment about
unnecessary copies below).
Please note that, currently, VSX is not enabled by default when targeting
anything because it is not yet ready for that. The assembler and disassembler
are fully implemented and tested. However:
- CodeGen support causes miscompiles; test-suite runtime failures:
MultiSource/Benchmarks/FreeBench/distray/distray
MultiSource/Benchmarks/McCat/08-main/main
MultiSource/Benchmarks/Olden/voronoi/voronoi
MultiSource/Benchmarks/mafft/pairlocalalign
MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4
SingleSource/Benchmarks/CoyoteBench/almabench
SingleSource/Benchmarks/Misc/matmul_f64_4x4
- The lowering currently falls back to using Altivec instructions far more
than it should. Worse, there are some things that are scalarized through the
stack that shouldn't be.
- A lot of unnecessary copies make it past the optimizers, and this needs to
be fixed.
- Many more regression tests are needed.
Normally, I'd fix these things prior to committing, but there are some
students and other contributors who would like to work this, and so it makes
sense to move this development process upstream where it can be subject to the
regular code-review procedures.
llvm-svn: 203768
2014-03-13 15:58:58 +08:00
|
|
|
HasVSX = false;
|
2014-10-11 01:21:15 +08:00
|
|
|
HasP8Vector = false;
|
2015-02-04 05:58:23 +08:00
|
|
|
HasP8Altivec = false;
|
2015-03-05 04:44:33 +08:00
|
|
|
HasP8Crypto = false;
|
2016-02-27 05:11:55 +08:00
|
|
|
HasP9Vector = false;
|
|
|
|
HasP9Altivec = false;
|
2013-08-19 13:01:02 +08:00
|
|
|
HasFCPSGN = false;
|
2013-07-16 06:29:40 +08:00
|
|
|
HasFSQRT = false;
|
|
|
|
HasFRE = false;
|
|
|
|
HasFRES = false;
|
|
|
|
HasFRSQRTE = false;
|
|
|
|
HasFRSQRTES = false;
|
|
|
|
HasRecipPrec = false;
|
|
|
|
HasSTFIWX = false;
|
|
|
|
HasLFIWAX = false;
|
|
|
|
HasFPRND = false;
|
|
|
|
HasFPCVT = false;
|
|
|
|
HasISEL = false;
|
2015-04-10 07:54:37 +08:00
|
|
|
HasBPERMD = false;
|
|
|
|
HasExtDiv = false;
|
2015-01-03 09:16:37 +08:00
|
|
|
HasCMPB = false;
|
2013-07-16 06:29:40 +08:00
|
|
|
HasLDBRX = false;
|
|
|
|
IsBookE = false;
|
2014-10-03 06:34:22 +08:00
|
|
|
HasOnlyMSYNC = false;
|
2014-08-04 23:47:38 +08:00
|
|
|
IsPPC4xx = false;
|
2014-08-05 01:07:41 +08:00
|
|
|
IsPPC6xx = false;
|
2014-08-04 23:47:38 +08:00
|
|
|
IsE500 = false;
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureMFTB = false;
|
2013-09-12 22:40:06 +08:00
|
|
|
DeprecatedDST = false;
|
2013-07-16 06:29:40 +08:00
|
|
|
HasLazyResolverStubs = false;
|
2015-01-15 04:17:10 +08:00
|
|
|
HasICBT = false;
|
[PowerPC] Loosen ELFv1 PPC64 func descriptor loads for indirect calls
Function pointers under PPC64 ELFv1 (which is used on PPC64/Linux on the
POWER7, A2 and earlier cores) are really pointers to a function descriptor, a
structure with three pointers: the actual pointer to the code to which to jump,
the pointer to the TOC needed by the callee, and an environment pointer. We
used to chain these loads, and make them opaque to the rest of the optimizer,
so that they'd always occur directly before the call. This is not necessary,
and in fact, highly suboptimal on embedded cores. Once the function pointer is
known, the loads can be performed ahead of time; in fact, they can be hoisted
out of loops.
Now these function descriptors are almost always generated by the linker, and
thus the contents of the descriptors are invariant. As a result, by default,
we'll mark the associated loads as invariant (allowing them to be hoisted out
of loops). I've added a target feature to turn this off, however, just in case
someone needs that option (constructing an on-stack descriptor, casting it to a
function pointer, and then calling it cannot be well-defined C/C++ code, but I
can imagine some JIT-compilation system doing so).
Consider this simple test:
$ cat call.c
typedef void (*fp)();
void bar(fp x) {
for (int i = 0; i < 1600000000; ++i)
x();
}
$ cat main.c
typedef void (*fp)();
void bar(fp x);
void foo() {}
int main() {
bar(foo);
}
On the PPC A2 (the BG/Q supercomputer), marking the function-descriptor loads
as invariant brings the execution time down to ~8 seconds from ~32 seconds with
the loads in the loop.
The difference on the POWER7 is smaller. Compiling with:
gcc -std=c99 -O3 -mcpu=native call.c main.c : ~6 seconds [this is 4.8.2]
clang -O3 -mcpu=native call.c main.c : ~5.3 seconds
clang -O3 -mcpu=native call.c main.c -mno-invariant-function-descriptors : ~4 seconds
(looks like we'd benefit from additional loop unrolling here, as a first
guess, because this is faster with the extra loads)
The -mno-invariant-function-descriptors will be added to Clang shortly.
llvm-svn: 226207
2015-01-16 05:17:34 +08:00
|
|
|
HasInvariantFunctionDescriptors = false;
|
2015-03-11 04:51:07 +08:00
|
|
|
HasPartwordAtomics = false;
|
2015-04-11 18:40:42 +08:00
|
|
|
HasDirectMove = false;
|
[PowerPC] Add support for the QPX vector instruction set
This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).
I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).
The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.
llvm-svn: 230413
2015-02-25 09:06:45 +08:00
|
|
|
IsQPXStackUnaligned = false;
|
2015-03-26 03:36:23 +08:00
|
|
|
HasHTM = false;
|
2015-11-21 06:38:20 +08:00
|
|
|
HasFusion = false;
|
2015-12-15 20:19:34 +08:00
|
|
|
HasFloat128 = false;
|
2016-03-31 23:26:37 +08:00
|
|
|
IsISA3_0 = false;
|
2016-08-30 08:59:23 +08:00
|
|
|
UseLongCalls = false;
|
2018-03-28 05:11:57 +08:00
|
|
|
SecurePlt = false;
|
2016-03-29 09:36:01 +08:00
|
|
|
|
|
|
|
HasPOPCNTD = POPCNTD_Unavailable;
|
2013-07-16 06:29:40 +08:00
|
|
|
}
|
|
|
|
|
2014-09-04 04:36:31 +08:00
|
|
|
void PPCSubtarget::initSubtargetFeatures(StringRef CPU, StringRef FS) {
|
2005-09-02 05:38:21 +08:00
|
|
|
// Determine default and user specified characteristics
|
2011-06-30 09:53:36 +08:00
|
|
|
std::string CPUName = CPU;
|
2016-03-01 00:42:27 +08:00
|
|
|
if (CPUName.empty() || CPU == "generic") {
|
2015-01-29 23:59:09 +08:00
|
|
|
// If cross-compiling with -march=ppc64le without -mcpu
|
|
|
|
if (TargetTriple.getArch() == Triple::ppc64le)
|
|
|
|
CPUName = "ppc64le";
|
|
|
|
else
|
|
|
|
CPUName = "generic";
|
|
|
|
}
|
2005-10-27 01:30:34 +08:00
|
|
|
|
2011-07-02 04:45:01 +08:00
|
|
|
// Initialize scheduling itinerary for the specified CPU.
|
|
|
|
InstrItins = getInstrItineraryForCPU(CPUName);
|
|
|
|
|
2012-10-25 20:27:42 +08:00
|
|
|
// Parse features string.
|
2014-10-02 04:38:26 +08:00
|
|
|
ParseSubtargetFeatures(CPUName, FS);
|
2012-10-25 20:27:42 +08:00
|
|
|
|
2006-06-17 01:50:12 +08:00
|
|
|
// If the user requested use of 64-bit regs, but the cpu selected doesn't
|
2008-02-16 02:40:53 +08:00
|
|
|
// support it, ignore.
|
2014-10-02 04:38:26 +08:00
|
|
|
if (IsPPC64 && has64BitSupport())
|
|
|
|
Use64BitRegs = true;
|
2006-12-12 07:22:45 +08:00
|
|
|
|
|
|
|
// Set up darwin-specific properties.
|
2009-08-12 06:49:34 +08:00
|
|
|
if (isDarwin())
|
2006-12-12 07:22:45 +08:00
|
|
|
HasLazyResolverStubs = true;
|
2013-01-31 07:43:27 +08:00
|
|
|
|
|
|
|
// QPX requires a 32-byte aligned stack. Note that we need to do this if
|
|
|
|
// we're compiling for a BG/Q system regardless of whether or not QPX
|
|
|
|
// is enabled because external functions will assume this alignment.
|
[PowerPC] Add support for the QPX vector instruction set
This adds support for the QPX vector instruction set, which is used by the
enhanced A2 cores on the IBM BG/Q supercomputers. QPX vectors are 256 bytes
wide, holding 4 double-precision floating-point values. Boolean values, modeled
here as <4 x i1> are actually also represented as floating-point values
(essentially { -1, 1 } for { false, true }). QPX shares many features with
Altivec and VSX, but is distinct from both of them. One major difference is
that, instead of adding completely-separate vector registers, QPX vector
registers are extensions of the scalar floating-point registers (lane 0 is the
corresponding scalar floating-point value). The operations supported on QPX
vectors mirrors that supported on the scalar floating-point values (with some
additional ones for permutations and logical/comparison operations).
I've been maintaining this support out-of-tree, as part of the bgclang project,
for several years. This is not the entire bgclang patch set, but is most of the
subset that can be cleanly integrated into LLVM proper at this time. Adding
this to the LLVM backend is part of my efforts to rebase bgclang to the current
LLVM trunk, but is independently useful (especially for codes that use LLVM as
a JIT in library form).
The assembler/disassembler test coverage is complete. The CodeGen test coverage
is not, but I've included some tests, and more will be added as follow-up work.
llvm-svn: 230413
2015-02-25 09:06:45 +08:00
|
|
|
IsQPXStackUnaligned = QPXStackUnaligned;
|
|
|
|
StackAlignment = getPlatformStackAlignment();
|
2013-07-26 09:35:43 +08:00
|
|
|
|
|
|
|
// Determine endianness.
|
2015-02-17 14:45:17 +08:00
|
|
|
// FIXME: Part of the TargetMachine.
|
2013-07-26 09:35:43 +08:00
|
|
|
IsLittleEndian = (TargetTriple.getArch() == Triple::ppc64le);
|
2006-12-12 07:22:45 +08:00
|
|
|
}
|
|
|
|
|
2016-06-24 04:50:42 +08:00
|
|
|
/// Return true if accesses to the specified global have to go through a dyld
|
|
|
|
/// lazy resolution stub. This means that an extra load is required to get the
|
|
|
|
/// address of the global.
|
2015-02-14 06:23:04 +08:00
|
|
|
bool PPCSubtarget::hasLazyResolverStub(const GlobalValue *GV) const {
|
2016-06-24 04:50:42 +08:00
|
|
|
if (!HasLazyResolverStubs)
|
2006-12-12 07:22:45 +08:00
|
|
|
return false;
|
2016-06-28 07:15:57 +08:00
|
|
|
if (!TM.shouldAssumeDSOLocal(*GV->getParent(), GV))
|
2016-06-24 04:50:42 +08:00
|
|
|
return true;
|
|
|
|
// 32 bit macho has no relocation for a-b if a is undefined, even if b is in
|
|
|
|
// the section that is being relocated. This means we have to use o load even
|
|
|
|
// for GVs that are known to be local to the dso.
|
|
|
|
if (GV->isDeclarationForLinker() || GV->hasCommonLinkage())
|
|
|
|
return true;
|
|
|
|
return false;
|
2005-08-04 15:12:09 +08:00
|
|
|
}
|
2011-12-02 12:58:02 +08:00
|
|
|
|
Add a scheduling model (with itinerary) for the PPC POWER7
This adds a scheduling model for the POWER7 (P7) core, and enables the
machine-instruction scheduler when targeting the P7. Scheduling for the P7,
like earlier ooo PPC cores, requires considering both dispatch group hazards,
and functional unit resources and latencies. These are both modeled in a
combined itinerary. Dispatch group formation is still handled by the post-RA
scheduler (which still needs to be updated for the P7, but nevertheless does a
pretty good job).
One interesting aspect of this change is that I've also enabled to use of AA
duing CodeGen for the P7 (just as it is for the embedded cores). The benchmark
results seem to support this decision (see below), and while this is normally
useful for in-order cores, and not for ooo cores like the P7, I think that the
dispatch slot hazards are enough like in-order resources to make the AA useful.
Test suite significant performance differences (where negative is a speedup,
and positive is a regression) vs. the current situation:
MultiSource/Benchmarks/BitBench/drop3/drop3
with AA: N/A
without AA: -28.7614% +/- 19.8356%
(significantly against AA)
MultiSource/Benchmarks/FreeBench/neural/neural
with AA: -17.7406% +/- 11.2712%
without AA: N/A
(significantly in favor of AA)
MultiSource/Benchmarks/SciMark2-C/scimark2
with AA: -11.2079% +/- 1.80543%
without AA: -11.3263% +/- 2.79651%
MultiSource/Benchmarks/TSVC/Symbolics-flt/Symbolics-flt
with AA: -41.8649% +/- 17.0053%
without AA: -34.5256% +/- 23.7072%
MultiSource/Benchmarks/mafft/pairlocalalign
with AA: 25.3016% +/- 17.8614%
without AA: 38.6629% +/- 14.9391%
(significantly in favor of AA)
MultiSource/Benchmarks/sim/sim
with AA: N/A
without AA: 13.4844% +/- 7.18195%
(significantly in favor of AA)
SingleSource/Benchmarks/BenchmarkGame/Large/fasta
with AA: 15.0664% +/- 6.70216%
without AA: 12.7747% +/- 8.43043%
SingleSource/Benchmarks/BenchmarkGame/puzzle
with AA: 82.2713% +/- 26.3567%
without AA: 75.7525% +/- 41.1842%
SingleSource/Benchmarks/Misc/flops-2
with AA: -37.1621% +/- 20.7964%
without AA: -35.2342% +/- 20.2999%
(significantly in favor of AA)
These are 99.5% confidence intervals from 5 runs per configuration. Regarding
the choice to turn on AA during CodeGen, of these results, four seem
significantly in favor of using AA, and one seems significantly against. I'm
not making this decision based on these numbers alone, but these results
seem consistent with results I have from other tests, and so I think that, on
balance, using AA is a win.
llvm-svn: 195981
2013-12-01 04:55:12 +08:00
|
|
|
// Embedded cores need aggressive scheduling (and some others also benefit).
|
2013-09-12 07:05:25 +08:00
|
|
|
static bool needsAggressiveScheduling(unsigned Directive) {
|
|
|
|
switch (Directive) {
|
|
|
|
default: return false;
|
|
|
|
case PPC::DIR_440:
|
|
|
|
case PPC::DIR_A2:
|
|
|
|
case PPC::DIR_E500mc:
|
|
|
|
case PPC::DIR_E5500:
|
Add a scheduling model (with itinerary) for the PPC POWER7
This adds a scheduling model for the POWER7 (P7) core, and enables the
machine-instruction scheduler when targeting the P7. Scheduling for the P7,
like earlier ooo PPC cores, requires considering both dispatch group hazards,
and functional unit resources and latencies. These are both modeled in a
combined itinerary. Dispatch group formation is still handled by the post-RA
scheduler (which still needs to be updated for the P7, but nevertheless does a
pretty good job).
One interesting aspect of this change is that I've also enabled to use of AA
duing CodeGen for the P7 (just as it is for the embedded cores). The benchmark
results seem to support this decision (see below), and while this is normally
useful for in-order cores, and not for ooo cores like the P7, I think that the
dispatch slot hazards are enough like in-order resources to make the AA useful.
Test suite significant performance differences (where negative is a speedup,
and positive is a regression) vs. the current situation:
MultiSource/Benchmarks/BitBench/drop3/drop3
with AA: N/A
without AA: -28.7614% +/- 19.8356%
(significantly against AA)
MultiSource/Benchmarks/FreeBench/neural/neural
with AA: -17.7406% +/- 11.2712%
without AA: N/A
(significantly in favor of AA)
MultiSource/Benchmarks/SciMark2-C/scimark2
with AA: -11.2079% +/- 1.80543%
without AA: -11.3263% +/- 2.79651%
MultiSource/Benchmarks/TSVC/Symbolics-flt/Symbolics-flt
with AA: -41.8649% +/- 17.0053%
without AA: -34.5256% +/- 23.7072%
MultiSource/Benchmarks/mafft/pairlocalalign
with AA: 25.3016% +/- 17.8614%
without AA: 38.6629% +/- 14.9391%
(significantly in favor of AA)
MultiSource/Benchmarks/sim/sim
with AA: N/A
without AA: 13.4844% +/- 7.18195%
(significantly in favor of AA)
SingleSource/Benchmarks/BenchmarkGame/Large/fasta
with AA: 15.0664% +/- 6.70216%
without AA: 12.7747% +/- 8.43043%
SingleSource/Benchmarks/BenchmarkGame/puzzle
with AA: 82.2713% +/- 26.3567%
without AA: 75.7525% +/- 41.1842%
SingleSource/Benchmarks/Misc/flops-2
with AA: -37.1621% +/- 20.7964%
without AA: -35.2342% +/- 20.2999%
(significantly in favor of AA)
These are 99.5% confidence intervals from 5 runs per configuration. Regarding
the choice to turn on AA during CodeGen, of these results, four seem
significantly in favor of using AA, and one seems significantly against. I'm
not making this decision based on these numbers alone, but these results
seem consistent with results I have from other tests, and so I think that, on
balance, using AA is a win.
llvm-svn: 195981
2013-12-01 04:55:12 +08:00
|
|
|
case PPC::DIR_PWR7:
|
2014-06-26 21:36:19 +08:00
|
|
|
case PPC::DIR_PWR8:
|
2016-05-10 02:54:58 +08:00
|
|
|
// FIXME: Same as P8 until POWER9 scheduling info is available
|
|
|
|
case PPC::DIR_PWR9:
|
2013-09-12 07:05:25 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool PPCSubtarget::enableMachineScheduler() const {
|
|
|
|
// Enable MI scheduling for the embedded cores.
|
|
|
|
// FIXME: Enable this for all cores (some additional modeling
|
|
|
|
// may be necessary).
|
|
|
|
return needsAggressiveScheduling(DarwinDirective);
|
|
|
|
}
|
|
|
|
|
2014-07-16 06:39:58 +08:00
|
|
|
// This overrides the PostRAScheduler bit in the SchedModel for each CPU.
|
2015-06-13 11:42:16 +08:00
|
|
|
bool PPCSubtarget::enablePostRAScheduler() const { return true; }
|
2014-07-16 06:39:58 +08:00
|
|
|
|
|
|
|
PPCGenSubtargetInfo::AntiDepBreakMode PPCSubtarget::getAntiDepBreakMode() const {
|
|
|
|
return TargetSubtargetInfo::ANTIDEP_ALL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void PPCSubtarget::getCriticalPathRCs(RegClassVector &CriticalPathRCs) const {
|
|
|
|
CriticalPathRCs.clear();
|
|
|
|
CriticalPathRCs.push_back(isPPC64() ?
|
|
|
|
&PPC::G8RCRegClass : &PPC::GPRCRegClass);
|
|
|
|
}
|
|
|
|
|
2013-09-12 07:05:25 +08:00
|
|
|
void PPCSubtarget::overrideSchedPolicy(MachineSchedPolicy &Policy,
|
|
|
|
unsigned NumRegionInstrs) const {
|
|
|
|
if (needsAggressiveScheduling(DarwinDirective)) {
|
|
|
|
Policy.OnlyTopDown = false;
|
|
|
|
Policy.OnlyBottomUp = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Spilling is generally expensive on all PPC cores, so always enable
|
|
|
|
// register-pressure tracking.
|
|
|
|
Policy.ShouldTrackPressure = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool PPCSubtarget::useAA() const {
|
|
|
|
// Use AA during code generation for the embedded cores.
|
|
|
|
return needsAggressiveScheduling(DarwinDirective);
|
|
|
|
}
|
|
|
|
|
2015-01-09 10:03:11 +08:00
|
|
|
bool PPCSubtarget::enableSubRegLiveness() const {
|
|
|
|
return UseSubRegLiveness;
|
|
|
|
}
|
|
|
|
|
2017-01-26 23:02:31 +08:00
|
|
|
unsigned char
|
|
|
|
PPCSubtarget::classifyGlobalReference(const GlobalValue *GV) const {
|
2015-11-21 04:51:31 +08:00
|
|
|
// Note that currently we don't generate non-pic references.
|
|
|
|
// If a caller wants that, this will have to be updated.
|
|
|
|
|
|
|
|
// Large code model always uses the TOC even for local symbols.
|
|
|
|
if (TM.getCodeModel() == CodeModel::Large)
|
|
|
|
return PPCII::MO_PIC_FLAG | PPCII::MO_NLP_FLAG;
|
|
|
|
|
2017-01-26 23:02:31 +08:00
|
|
|
if (TM.shouldAssumeDSOLocal(*GV->getParent(), GV))
|
|
|
|
return PPCII::MO_PIC_FLAG;
|
|
|
|
return PPCII::MO_PIC_FLAG | PPCII::MO_NLP_FLAG;
|
2015-11-21 04:51:31 +08:00
|
|
|
}
|
|
|
|
|
2015-02-17 14:45:15 +08:00
|
|
|
bool PPCSubtarget::isELFv2ABI() const { return TM.isELFv2ABI(); }
|
|
|
|
bool PPCSubtarget::isPPC64() const { return TM.isPPC64(); }
|