2012-02-18 20:03:15 +08:00
|
|
|
//===-- PPCSubtarget.h - Define Subtarget for the PPC ----------*- C++ -*--===//
|
2005-08-04 15:12:09 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2005-08-04 15:12:09 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2011-07-02 05:01:15 +08:00
|
|
|
// This file declares the PowerPC specific subclass of TargetSubtargetInfo.
|
2005-08-04 15:12:09 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2014-08-14 00:26:38 +08:00
|
|
|
#ifndef LLVM_LIB_TARGET_POWERPC_PPCSUBTARGET_H
|
|
|
|
#define LLVM_LIB_TARGET_POWERPC_PPCSUBTARGET_H
|
2005-08-04 15:12:09 +08:00
|
|
|
|
2014-06-13 04:54:11 +08:00
|
|
|
#include "PPCFrameLowering.h"
|
2014-06-13 06:50:10 +08:00
|
|
|
#include "PPCISelLowering.h"
|
2015-01-14 19:23:27 +08:00
|
|
|
#include "PPCInstrInfo.h"
|
2011-06-29 09:14:12 +08:00
|
|
|
#include "llvm/ADT/Triple.h"
|
2020-08-18 04:33:47 +08:00
|
|
|
#include "llvm/CodeGen/GlobalISel/CallLowering.h"
|
|
|
|
#include "llvm/CodeGen/GlobalISel/LegalizerInfo.h"
|
|
|
|
#include "llvm/CodeGen/GlobalISel/RegisterBankInfo.h"
|
2016-01-28 00:32:26 +08:00
|
|
|
#include "llvm/CodeGen/SelectionDAGTargetInfo.h"
|
2017-11-17 09:07:10 +08:00
|
|
|
#include "llvm/CodeGen/TargetSubtargetInfo.h"
|
2014-06-13 05:08:06 +08:00
|
|
|
#include "llvm/IR/DataLayout.h"
|
2012-12-04 15:12:27 +08:00
|
|
|
#include "llvm/MC/MCInstrItineraries.h"
|
2005-09-02 05:38:21 +08:00
|
|
|
#include <string>
|
|
|
|
|
2011-07-02 04:45:01 +08:00
|
|
|
#define GET_SUBTARGETINFO_HEADER
|
2011-07-02 06:36:09 +08:00
|
|
|
#include "PPCGenSubtargetInfo.inc"
|
2011-07-02 04:45:01 +08:00
|
|
|
|
2007-01-19 12:36:02 +08:00
|
|
|
// GCC #defines PPC on Linux but we use it as our namespace name
|
|
|
|
#undef PPC
|
|
|
|
|
2005-08-04 15:12:09 +08:00
|
|
|
namespace llvm {
|
2011-07-07 15:07:08 +08:00
|
|
|
class StringRef;
|
2006-12-13 04:57:08 +08:00
|
|
|
|
|
|
|
namespace PPC {
|
|
|
|
// -m directive values.
|
[PowerPC] Add support for -mcpu=pwr10 in both clang and llvm
Summary:
This patch simply adds support for the new CPU in anticipation of
Power10. There isn't really any functionality added so there are no
associated test cases at this time.
Reviewers: stefanp, nemanjai, amyk, hfinkel, power-llvm-team, #powerpc
Reviewed By: stefanp, nemanjai, amyk, #powerpc
Subscribers: NeHuang, steven.zhang, hiraditya, llvm-commits, wuzish, shchenz, cfe-commits, kbarton, echristo
Tags: #clang, #powerpc, #llvm
Differential Revision: https://reviews.llvm.org/D80020
2020-05-27 22:50:14 +08:00
|
|
|
enum {
|
|
|
|
DIR_NONE,
|
|
|
|
DIR_32,
|
|
|
|
DIR_440,
|
|
|
|
DIR_601,
|
|
|
|
DIR_602,
|
|
|
|
DIR_603,
|
|
|
|
DIR_7400,
|
|
|
|
DIR_750,
|
|
|
|
DIR_970,
|
|
|
|
DIR_A2,
|
|
|
|
DIR_E500,
|
|
|
|
DIR_E500mc,
|
|
|
|
DIR_E5500,
|
|
|
|
DIR_PWR3,
|
|
|
|
DIR_PWR4,
|
|
|
|
DIR_PWR5,
|
|
|
|
DIR_PWR5X,
|
|
|
|
DIR_PWR6,
|
|
|
|
DIR_PWR6X,
|
|
|
|
DIR_PWR7,
|
|
|
|
DIR_PWR8,
|
|
|
|
DIR_PWR9,
|
|
|
|
DIR_PWR10,
|
|
|
|
DIR_PWR_FUTURE,
|
|
|
|
DIR_64
|
|
|
|
};
|
2015-06-23 17:49:53 +08:00
|
|
|
}
|
2006-12-13 04:57:08 +08:00
|
|
|
|
2006-12-12 07:22:45 +08:00
|
|
|
class GlobalValue;
|
2012-10-29 23:51:35 +08:00
|
|
|
|
2011-07-02 04:45:01 +08:00
|
|
|
class PPCSubtarget : public PPCGenSubtargetInfo {
|
2016-03-29 09:36:01 +08:00
|
|
|
public:
|
|
|
|
enum POPCNTDKind {
|
|
|
|
POPCNTD_Unavailable,
|
|
|
|
POPCNTD_Slow,
|
|
|
|
POPCNTD_Fast
|
|
|
|
};
|
|
|
|
|
2005-08-04 15:12:09 +08:00
|
|
|
protected:
|
2014-08-09 12:38:56 +08:00
|
|
|
/// TargetTriple - What processor and OS we're targeting.
|
|
|
|
Triple TargetTriple;
|
|
|
|
|
2005-08-04 15:12:09 +08:00
|
|
|
/// stackAlignment - The minimum alignment known to hold of the stack frame on
|
|
|
|
/// entry to the function and which must be maintained by every function.
|
[Alignment][NFC] Use Align for TargetFrameLowering/Subtarget
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68993
llvm-svn: 375084
2019-10-17 15:49:39 +08:00
|
|
|
Align StackAlignment;
|
2012-10-29 23:51:35 +08:00
|
|
|
|
2005-11-02 04:06:59 +08:00
|
|
|
/// Selected instruction itineraries (one entry per itinerary class.)
|
|
|
|
InstrItineraryData InstrItins;
|
2012-10-29 23:51:35 +08:00
|
|
|
|
2006-12-13 04:57:08 +08:00
|
|
|
/// Which cpu directive was used.
|
[PowerPC] Rename DarwinDirective to CPUDirective (NFC)
Summary:
This patch renames the DarwinDirective (used to identify which CPU was defined)
to CPUDirective. It also adds the getCPUDirective() method and replaces all uses
of getDarwinDirective() with getCPUDirective().
Once this patch lands and downstream users of the getDarwinDirective() method
have switched to the getCPUDirective() method, the old getDarwinDirective()
method will be removed.
Reviewers: nemanjai, hfinkel, power-llvm-team, jsji, echristo, #powerpc, jhibbits
Reviewed By: hfinkel, jsji, jhibbits
Subscribers: hiraditya, shchenz, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70352
2019-11-16 05:48:34 +08:00
|
|
|
unsigned CPUDirective;
|
2005-08-04 15:12:09 +08:00
|
|
|
|
|
|
|
/// Used by the ISel to turn in optimizations for POWER4-derived architectures
|
2012-06-12 03:57:01 +08:00
|
|
|
bool HasMFOCRF;
|
2006-06-17 01:34:12 +08:00
|
|
|
bool Has64BitSupport;
|
|
|
|
bool Use64BitRegs;
|
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
|
|
|
bool UseCRBits;
|
[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
|
|
|
bool HasHardFloat;
|
2006-06-17 01:50:12 +08:00
|
|
|
bool IsPPC64;
|
2005-10-27 01:30:34 +08:00
|
|
|
bool HasAltivec;
|
2018-07-18 12:25:10 +08:00
|
|
|
bool HasFPU;
|
2014-08-07 20:18:21 +08:00
|
|
|
bool HasSPE;
|
2021-01-12 23:46:11 +08:00
|
|
|
bool HasEFPU2;
|
2013-10-17 04:38:58 +08:00
|
|
|
bool HasVSX;
|
2019-05-07 21:48:03 +08:00
|
|
|
bool NeedsTwoConstNR;
|
2014-10-11 01:21:15 +08:00
|
|
|
bool HasP8Vector;
|
2015-02-04 05:58:23 +08:00
|
|
|
bool HasP8Altivec;
|
2015-03-05 04:44:33 +08:00
|
|
|
bool HasP8Crypto;
|
2016-02-27 05:11:55 +08:00
|
|
|
bool HasP9Vector;
|
|
|
|
bool HasP9Altivec;
|
[PowerPC] Add -m[no-]power10-vector clang and llvm option
Summary: This patch adds command line option for enabling power10-vector support.
Reviewers: hfinkel, nemanjai, lei, amyk, #powerpc
Reviewed By: lei, amyk, #powerpc
Subscribers: wuzish, kbarton, hiraditya, shchenz, cfe-commits, llvm-commits
Tags: #llvm, #clang, #powerpc
Differential Revision: https://reviews.llvm.org/D80758
2020-06-17 03:39:18 +08:00
|
|
|
bool HasP10Vector;
|
2020-01-24 04:01:02 +08:00
|
|
|
bool HasPrefixInstrs;
|
2020-01-28 22:22:53 +08:00
|
|
|
bool HasPCRelativeMemops;
|
2020-08-24 22:14:16 +08:00
|
|
|
bool HasMMA;
|
2021-03-23 21:20:08 +08:00
|
|
|
bool HasROPProtect;
|
2021-03-23 23:31:52 +08:00
|
|
|
bool HasPrivileged;
|
2013-08-19 13:01:02 +08:00
|
|
|
bool HasFCPSGN;
|
2005-09-03 02:33:05 +08:00
|
|
|
bool HasFSQRT;
|
2013-04-03 12:01:11 +08:00
|
|
|
bool HasFRE, HasFRES, HasFRSQRTE, HasFRSQRTES;
|
|
|
|
bool HasRecipPrec;
|
2006-02-28 15:08:22 +08:00
|
|
|
bool HasSTFIWX;
|
2013-03-31 18:12:51 +08:00
|
|
|
bool HasLFIWAX;
|
2013-03-29 16:57:48 +08:00
|
|
|
bool HasFPRND;
|
2013-04-02 01:52:07 +08:00
|
|
|
bool HasFPCVT;
|
2012-06-23 07:10:08 +08:00
|
|
|
bool HasISEL;
|
2015-04-10 07:54:37 +08:00
|
|
|
bool HasBPERMD;
|
|
|
|
bool HasExtDiv;
|
2015-01-03 09:16:37 +08:00
|
|
|
bool HasCMPB;
|
2013-03-29 03:25:55 +08:00
|
|
|
bool HasLDBRX;
|
2011-10-17 12:03:49 +08:00
|
|
|
bool IsBookE;
|
2014-10-03 06:34:22 +08:00
|
|
|
bool HasOnlyMSYNC;
|
2014-08-04 23:47:38 +08:00
|
|
|
bool IsE500;
|
|
|
|
bool IsPPC4xx;
|
2014-08-05 01:07:41 +08:00
|
|
|
bool IsPPC6xx;
|
2015-06-17 00:01:15 +08:00
|
|
|
bool FeatureMFTB;
|
2019-12-29 01:20:36 +08:00
|
|
|
bool AllowsUnalignedFPAccess;
|
2013-09-12 22:40:06 +08:00
|
|
|
bool DeprecatedDST;
|
2013-07-26 09:35:43 +08:00
|
|
|
bool IsLittleEndian;
|
2015-01-15 04:17:10 +08:00
|
|
|
bool HasICBT;
|
[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
|
|
|
bool HasInvariantFunctionDescriptors;
|
2015-03-11 04:51:07 +08:00
|
|
|
bool HasPartwordAtomics;
|
2021-07-15 08:49:42 +08:00
|
|
|
bool HasQuadwordAtomics;
|
2015-04-11 18:40:42 +08:00
|
|
|
bool HasDirectMove;
|
2015-03-26 03:36:23 +08:00
|
|
|
bool HasHTM;
|
2015-12-15 20:19:34 +08:00
|
|
|
bool HasFloat128;
|
2020-03-12 13:15:41 +08:00
|
|
|
bool HasFusion;
|
2020-09-13 19:39:49 +08:00
|
|
|
bool HasStoreFusion;
|
2020-03-12 13:15:41 +08:00
|
|
|
bool HasAddiLoadFusion;
|
|
|
|
bool HasAddisLoadFusion;
|
2021-07-14 02:12:58 +08:00
|
|
|
bool IsISA2_07;
|
2016-03-31 23:26:37 +08:00
|
|
|
bool IsISA3_0;
|
[PowerPC] Add support for -mcpu=pwr10 in both clang and llvm
Summary:
This patch simply adds support for the new CPU in anticipation of
Power10. There isn't really any functionality added so there are no
associated test cases at this time.
Reviewers: stefanp, nemanjai, amyk, hfinkel, power-llvm-team, #powerpc
Reviewed By: stefanp, nemanjai, amyk, #powerpc
Subscribers: NeHuang, steven.zhang, hiraditya, llvm-commits, wuzish, shchenz, cfe-commits, kbarton, echristo
Tags: #clang, #powerpc, #llvm
Differential Revision: https://reviews.llvm.org/D80020
2020-05-27 22:50:14 +08:00
|
|
|
bool IsISA3_1;
|
2016-08-30 08:59:23 +08:00
|
|
|
bool UseLongCalls;
|
2018-03-27 19:23:53 +08:00
|
|
|
bool SecurePlt;
|
2019-01-26 09:18:48 +08:00
|
|
|
bool VectorsUseTwoUnits;
|
2019-03-27 11:50:16 +08:00
|
|
|
bool UsePPCPreRASchedStrategy;
|
|
|
|
bool UsePPCPostRASchedStrategy;
|
2020-07-29 05:02:50 +08:00
|
|
|
bool PairedVectorMemops;
|
2020-05-11 23:02:09 +08:00
|
|
|
bool PredictableSelectIsExpensive;
|
2021-01-15 04:35:56 +08:00
|
|
|
bool HasModernAIXAs;
|
|
|
|
bool IsAIX;
|
2016-03-29 09:36:01 +08:00
|
|
|
|
|
|
|
POPCNTDKind HasPOPCNTD;
|
2012-10-29 23:51:35 +08:00
|
|
|
|
2015-02-14 06:48:51 +08:00
|
|
|
const PPCTargetMachine &TM;
|
2014-06-13 06:28:06 +08:00
|
|
|
PPCFrameLowering FrameLowering;
|
2014-06-13 06:05:46 +08:00
|
|
|
PPCInstrInfo InstrInfo;
|
2014-06-13 06:50:10 +08:00
|
|
|
PPCTargetLowering TLInfo;
|
2016-01-28 00:32:26 +08:00
|
|
|
SelectionDAGTargetInfo TSInfo;
|
2014-06-13 05:08:06 +08:00
|
|
|
|
2020-08-18 04:33:47 +08:00
|
|
|
/// GlobalISel related APIs.
|
|
|
|
std::unique_ptr<CallLowering> CallLoweringInfo;
|
|
|
|
std::unique_ptr<LegalizerInfo> Legalizer;
|
|
|
|
std::unique_ptr<RegisterBankInfo> RegBankInfo;
|
|
|
|
std::unique_ptr<InstructionSelector> InstSelector;
|
|
|
|
|
2005-08-04 15:12:09 +08:00
|
|
|
public:
|
|
|
|
/// This constructor initializes the data members to match that
|
2009-08-03 06:11:08 +08:00
|
|
|
/// of the specified triple.
|
2005-08-04 15:12:09 +08:00
|
|
|
///
|
2015-06-10 20:11:26 +08:00
|
|
|
PPCSubtarget(const Triple &TT, const std::string &CPU, const std::string &FS,
|
|
|
|
const PPCTargetMachine &TM);
|
2012-10-29 23:51:35 +08:00
|
|
|
|
|
|
|
/// ParseSubtargetFeatures - Parses features string setting specified
|
2005-10-27 02:07:50 +08:00
|
|
|
/// subtarget options. Definition of function is auto generated by tblgen.
|
2020-08-15 05:56:54 +08:00
|
|
|
void ParseSubtargetFeatures(StringRef CPU, StringRef TuneCPU, StringRef FS);
|
2012-10-29 23:51:35 +08:00
|
|
|
|
2005-08-04 15:12:09 +08:00
|
|
|
/// getStackAlignment - Returns the minimum alignment known to hold of the
|
|
|
|
/// stack frame on entry to the function and which must be maintained by every
|
|
|
|
/// function for this subtarget.
|
[Alignment][NFC] Use Align for TargetFrameLowering/Subtarget
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68993
llvm-svn: 375084
2019-10-17 15:49:39 +08:00
|
|
|
Align getStackAlignment() const { return StackAlignment; }
|
2012-10-29 23:51:35 +08:00
|
|
|
|
[PowerPC] Rename DarwinDirective to CPUDirective (NFC)
Summary:
This patch renames the DarwinDirective (used to identify which CPU was defined)
to CPUDirective. It also adds the getCPUDirective() method and replaces all uses
of getDarwinDirective() with getCPUDirective().
Once this patch lands and downstream users of the getDarwinDirective() method
have switched to the getCPUDirective() method, the old getDarwinDirective()
method will be removed.
Reviewers: nemanjai, hfinkel, power-llvm-team, jsji, echristo, #powerpc, jhibbits
Reviewed By: hfinkel, jsji, jhibbits
Subscribers: hiraditya, shchenz, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70352
2019-11-16 05:48:34 +08:00
|
|
|
/// getCPUDirective - Returns the -m directive specified for the cpu.
|
2006-12-13 04:57:08 +08:00
|
|
|
///
|
[PowerPC] Rename DarwinDirective to CPUDirective (NFC)
Summary:
This patch renames the DarwinDirective (used to identify which CPU was defined)
to CPUDirective. It also adds the getCPUDirective() method and replaces all uses
of getDarwinDirective() with getCPUDirective().
Once this patch lands and downstream users of the getDarwinDirective() method
have switched to the getCPUDirective() method, the old getDarwinDirective()
method will be removed.
Reviewers: nemanjai, hfinkel, power-llvm-team, jsji, echristo, #powerpc, jhibbits
Reviewed By: hfinkel, jsji, jhibbits
Subscribers: hiraditya, shchenz, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70352
2019-11-16 05:48:34 +08:00
|
|
|
unsigned getCPUDirective() const { return CPUDirective; }
|
2012-10-29 23:51:35 +08:00
|
|
|
|
2014-06-14 06:38:48 +08:00
|
|
|
/// getInstrItins - Return the instruction itineraries based on subtarget
|
2005-11-02 04:06:59 +08:00
|
|
|
/// selection.
|
2014-08-05 05:25:23 +08:00
|
|
|
const InstrItineraryData *getInstrItineraryData() const override {
|
|
|
|
return &InstrItins;
|
|
|
|
}
|
|
|
|
|
|
|
|
const PPCFrameLowering *getFrameLowering() const override {
|
|
|
|
return &FrameLowering;
|
|
|
|
}
|
|
|
|
const PPCInstrInfo *getInstrInfo() const override { return &InstrInfo; }
|
|
|
|
const PPCTargetLowering *getTargetLowering() const override {
|
|
|
|
return &TLInfo;
|
|
|
|
}
|
2016-01-28 00:32:26 +08:00
|
|
|
const SelectionDAGTargetInfo *getSelectionDAGInfo() const override {
|
2014-08-05 05:25:23 +08:00
|
|
|
return &TSInfo;
|
|
|
|
}
|
|
|
|
const PPCRegisterInfo *getRegisterInfo() const override {
|
|
|
|
return &getInstrInfo()->getRegisterInfo();
|
|
|
|
}
|
2015-02-14 06:23:04 +08:00
|
|
|
const PPCTargetMachine &getTargetMachine() const { return TM; }
|
2014-06-13 04:54:11 +08:00
|
|
|
|
|
|
|
/// initializeSubtargetDependencies - Initializes using a CPU and feature string
|
|
|
|
/// so that we can use initializer lists for subtarget initialization.
|
|
|
|
PPCSubtarget &initializeSubtargetDependencies(StringRef CPU, StringRef FS);
|
|
|
|
|
2013-07-16 06:29:40 +08:00
|
|
|
private:
|
|
|
|
void initializeEnvironment();
|
2014-09-04 04:36:31 +08:00
|
|
|
void initSubtargetFeatures(StringRef CPU, StringRef FS);
|
2013-07-16 06:29:40 +08:00
|
|
|
|
|
|
|
public:
|
2006-06-17 01:50:12 +08:00
|
|
|
/// isPPC64 - Return true if we are generating code for 64-bit pointer mode.
|
|
|
|
///
|
2015-02-17 14:45:15 +08:00
|
|
|
bool isPPC64() const;
|
2012-10-29 23:51:35 +08:00
|
|
|
|
2006-06-17 01:50:12 +08:00
|
|
|
/// has64BitSupport - Return true if the selected CPU supports 64-bit
|
|
|
|
/// instructions, regardless of whether we are in 32-bit or 64-bit mode.
|
|
|
|
bool has64BitSupport() const { return Has64BitSupport; }
|
2015-12-15 01:57:33 +08:00
|
|
|
// useSoftFloat - Return true if soft-float option is turned on.
|
2019-08-14 22:13:11 +08:00
|
|
|
bool useSoftFloat() const {
|
|
|
|
if (isAIXABI() && !HasHardFloat)
|
|
|
|
report_fatal_error("soft-float is not yet supported on AIX.");
|
|
|
|
return !HasHardFloat;
|
|
|
|
}
|
2012-10-29 23:51:35 +08:00
|
|
|
|
2006-06-17 01:50:12 +08:00
|
|
|
/// use64BitRegs - Return true if in 64-bit mode or if we should use 64-bit
|
|
|
|
/// registers in 32-bit mode when possible. This can only true if
|
|
|
|
/// has64BitSupport() returns true.
|
|
|
|
bool use64BitRegs() const { return Use64BitRegs; }
|
2012-10-29 23:51:35 +08:00
|
|
|
|
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 - Return true if we should store and manipulate i1 values in
|
|
|
|
/// the individual condition register bits.
|
|
|
|
bool useCRBits() const { return UseCRBits; }
|
|
|
|
|
2013-07-26 09:35:43 +08:00
|
|
|
// isLittleEndian - True if generating little-endian code
|
|
|
|
bool isLittleEndian() const { return IsLittleEndian; }
|
|
|
|
|
2006-06-17 01:50:12 +08:00
|
|
|
// Specific obvious features.
|
2013-08-19 13:01:02 +08:00
|
|
|
bool hasFCPSGN() const { return HasFCPSGN; }
|
2005-09-03 02:33:05 +08:00
|
|
|
bool hasFSQRT() const { return HasFSQRT; }
|
2013-04-03 12:01:11 +08:00
|
|
|
bool hasFRE() const { return HasFRE; }
|
|
|
|
bool hasFRES() const { return HasFRES; }
|
|
|
|
bool hasFRSQRTE() const { return HasFRSQRTE; }
|
|
|
|
bool hasFRSQRTES() const { return HasFRSQRTES; }
|
|
|
|
bool hasRecipPrec() const { return HasRecipPrec; }
|
2006-02-28 15:08:22 +08:00
|
|
|
bool hasSTFIWX() const { return HasSTFIWX; }
|
2013-03-31 18:12:51 +08:00
|
|
|
bool hasLFIWAX() const { return HasLFIWAX; }
|
2013-03-29 16:57:48 +08:00
|
|
|
bool hasFPRND() const { return HasFPRND; }
|
2013-04-02 01:52:07 +08:00
|
|
|
bool hasFPCVT() const { return HasFPCVT; }
|
2005-10-27 01:30:34 +08:00
|
|
|
bool hasAltivec() const { return HasAltivec; }
|
2014-08-07 20:18:21 +08:00
|
|
|
bool hasSPE() const { return HasSPE; }
|
2021-01-12 23:46:11 +08:00
|
|
|
bool hasEFPU2() const { return HasEFPU2; }
|
2018-07-18 12:25:10 +08:00
|
|
|
bool hasFPU() const { return HasFPU; }
|
[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
|
|
|
bool hasVSX() const { return HasVSX; }
|
2019-05-07 21:48:03 +08:00
|
|
|
bool needsTwoConstNR() const { return NeedsTwoConstNR; }
|
2014-10-11 01:21:15 +08:00
|
|
|
bool hasP8Vector() const { return HasP8Vector; }
|
2015-02-04 05:58:23 +08:00
|
|
|
bool hasP8Altivec() const { return HasP8Altivec; }
|
2015-03-05 04:44:33 +08:00
|
|
|
bool hasP8Crypto() const { return HasP8Crypto; }
|
2016-02-27 05:11:55 +08:00
|
|
|
bool hasP9Vector() const { return HasP9Vector; }
|
|
|
|
bool hasP9Altivec() const { return HasP9Altivec; }
|
[PowerPC] Add -m[no-]power10-vector clang and llvm option
Summary: This patch adds command line option for enabling power10-vector support.
Reviewers: hfinkel, nemanjai, lei, amyk, #powerpc
Reviewed By: lei, amyk, #powerpc
Subscribers: wuzish, kbarton, hiraditya, shchenz, cfe-commits, llvm-commits
Tags: #llvm, #clang, #powerpc
Differential Revision: https://reviews.llvm.org/D80758
2020-06-17 03:39:18 +08:00
|
|
|
bool hasP10Vector() const { return HasP10Vector; }
|
2020-01-24 04:01:02 +08:00
|
|
|
bool hasPrefixInstrs() const { return HasPrefixInstrs; }
|
2020-01-28 22:22:53 +08:00
|
|
|
bool hasPCRelativeMemops() const { return HasPCRelativeMemops; }
|
2020-08-24 22:14:16 +08:00
|
|
|
bool hasMMA() const { return HasMMA; }
|
2021-03-23 21:20:08 +08:00
|
|
|
bool hasROPProtect() const { return HasROPProtect; }
|
2021-03-23 23:31:52 +08:00
|
|
|
bool hasPrivileged() const { return HasPrivileged; }
|
2020-07-29 05:02:50 +08:00
|
|
|
bool pairedVectorMemops() const { return PairedVectorMemops; }
|
2012-06-12 03:57:01 +08:00
|
|
|
bool hasMFOCRF() const { return HasMFOCRF; }
|
2012-06-23 07:10:08 +08:00
|
|
|
bool hasISEL() const { return HasISEL; }
|
2015-04-10 07:54:37 +08:00
|
|
|
bool hasBPERMD() const { return HasBPERMD; }
|
|
|
|
bool hasExtDiv() const { return HasExtDiv; }
|
2015-01-03 09:16:37 +08:00
|
|
|
bool hasCMPB() const { return HasCMPB; }
|
2013-03-29 03:25:55 +08:00
|
|
|
bool hasLDBRX() const { return HasLDBRX; }
|
2011-10-17 12:03:49 +08:00
|
|
|
bool isBookE() const { return IsBookE; }
|
2014-10-03 06:34:22 +08:00
|
|
|
bool hasOnlyMSYNC() const { return HasOnlyMSYNC; }
|
2014-08-04 23:47:38 +08:00
|
|
|
bool isPPC4xx() const { return IsPPC4xx; }
|
2014-08-05 01:07:41 +08:00
|
|
|
bool isPPC6xx() const { return IsPPC6xx; }
|
2018-03-27 19:23:53 +08:00
|
|
|
bool isSecurePlt() const {return SecurePlt; }
|
2019-01-26 09:18:48 +08:00
|
|
|
bool vectorsUseTwoUnits() const {return VectorsUseTwoUnits; }
|
2014-08-04 23:47:38 +08:00
|
|
|
bool isE500() const { return IsE500; }
|
2015-06-17 00:01:15 +08:00
|
|
|
bool isFeatureMFTB() const { return FeatureMFTB; }
|
2019-12-29 01:20:36 +08:00
|
|
|
bool allowsUnalignedFPAccess() const { return AllowsUnalignedFPAccess; }
|
2013-09-12 22:40:06 +08:00
|
|
|
bool isDeprecatedDST() const { return DeprecatedDST; }
|
2015-01-15 04:17:10 +08:00
|
|
|
bool hasICBT() const { return HasICBT; }
|
[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
|
|
|
bool hasInvariantFunctionDescriptors() const {
|
|
|
|
return HasInvariantFunctionDescriptors;
|
|
|
|
}
|
2019-03-27 11:50:16 +08:00
|
|
|
bool usePPCPreRASchedStrategy() const { return UsePPCPreRASchedStrategy; }
|
|
|
|
bool usePPCPostRASchedStrategy() const { return UsePPCPostRASchedStrategy; }
|
2015-03-11 04:51:07 +08:00
|
|
|
bool hasPartwordAtomics() const { return HasPartwordAtomics; }
|
2021-07-15 08:49:42 +08:00
|
|
|
bool hasQuadwordAtomics() const { return HasQuadwordAtomics; }
|
2015-04-11 18:40:42 +08:00
|
|
|
bool hasDirectMove() const { return HasDirectMove; }
|
2007-01-16 17:29:17 +08:00
|
|
|
|
[Alignment][NFC] Use Align for TargetFrameLowering/Subtarget
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, hiraditya, aheejin, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, jsji, Jim, lenary, s.egerton, pzheng, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68993
llvm-svn: 375084
2019-10-17 15:49:39 +08:00
|
|
|
Align getPlatformStackAlignment() const {
|
|
|
|
return Align(16);
|
[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
|
|
|
}
|
2017-07-12 00:42:20 +08:00
|
|
|
|
2020-02-11 02:52:08 +08:00
|
|
|
unsigned getRedZoneSize() const {
|
|
|
|
if (isPPC64())
|
|
|
|
// 288 bytes = 18*8 (FPRs) + 18*8 (GPRs, GPR13 reserved)
|
|
|
|
return 288;
|
|
|
|
|
|
|
|
// AIX PPC32: 220 bytes = 18*8 (FPRs) + 19*4 (GPRs);
|
|
|
|
// PPC32 SVR4ABI has no redzone.
|
|
|
|
return isAIXABI() ? 220 : 0;
|
|
|
|
}
|
2017-07-12 00:42:20 +08:00
|
|
|
|
2015-03-26 03:36:23 +08:00
|
|
|
bool hasHTM() const { return HasHTM; }
|
2015-12-15 20:19:34 +08:00
|
|
|
bool hasFloat128() const { return HasFloat128; }
|
2021-07-14 02:12:58 +08:00
|
|
|
bool isISA2_07() const { return IsISA2_07; }
|
2016-03-31 23:26:37 +08:00
|
|
|
bool isISA3_0() const { return IsISA3_0; }
|
[PowerPC] Add support for -mcpu=pwr10 in both clang and llvm
Summary:
This patch simply adds support for the new CPU in anticipation of
Power10. There isn't really any functionality added so there are no
associated test cases at this time.
Reviewers: stefanp, nemanjai, amyk, hfinkel, power-llvm-team, #powerpc
Reviewed By: stefanp, nemanjai, amyk, #powerpc
Subscribers: NeHuang, steven.zhang, hiraditya, llvm-commits, wuzish, shchenz, cfe-commits, kbarton, echristo
Tags: #clang, #powerpc, #llvm
Differential Revision: https://reviews.llvm.org/D80020
2020-05-27 22:50:14 +08:00
|
|
|
bool isISA3_1() const { return IsISA3_1; }
|
2016-08-30 08:59:23 +08:00
|
|
|
bool useLongCalls() const { return UseLongCalls; }
|
2020-03-12 13:15:41 +08:00
|
|
|
bool hasFusion() const { return HasFusion; }
|
2020-09-13 19:39:49 +08:00
|
|
|
bool hasStoreFusion() const { return HasStoreFusion; }
|
2020-03-12 13:15:41 +08:00
|
|
|
bool hasAddiLoadFusion() const { return HasAddiLoadFusion; }
|
|
|
|
bool hasAddisLoadFusion() const { return HasAddisLoadFusion; }
|
2016-09-22 17:52:19 +08:00
|
|
|
bool needsSwapsForVSXMemOps() const {
|
|
|
|
return hasVSX() && isLittleEndian() && !hasP9Vector();
|
|
|
|
}
|
[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
|
|
|
|
2016-03-29 09:36:01 +08:00
|
|
|
POPCNTDKind hasPOPCNTD() const { return HasPOPCNTD; }
|
|
|
|
|
2011-04-20 04:54:28 +08:00
|
|
|
const Triple &getTargetTriple() const { return TargetTriple; }
|
|
|
|
|
2014-07-19 07:29:49 +08:00
|
|
|
bool isTargetELF() const { return TargetTriple.isOSBinFormatELF(); }
|
|
|
|
bool isTargetMachO() const { return TargetTriple.isOSBinFormatMachO(); }
|
2016-04-20 04:14:52 +08:00
|
|
|
bool isTargetLinux() const { return TargetTriple.isOSLinux(); }
|
2014-07-19 07:29:49 +08:00
|
|
|
|
2019-05-25 04:54:35 +08:00
|
|
|
bool isAIXABI() const { return TargetTriple.isOSAIX(); }
|
2020-01-02 14:47:15 +08:00
|
|
|
bool isSVR4ABI() const { return !isAIXABI(); }
|
2015-02-17 14:45:15 +08:00
|
|
|
bool isELFv2ABI() const;
|
2009-08-15 19:54:46 +08:00
|
|
|
|
2019-08-22 23:11:28 +08:00
|
|
|
bool is64BitELFABI() const { return isSVR4ABI() && isPPC64(); }
|
|
|
|
bool is32BitELFABI() const { return isSVR4ABI() && !isPPC64(); }
|
2020-04-08 21:07:35 +08:00
|
|
|
bool isUsingPCRelativeCalls() const;
|
2019-08-22 23:11:28 +08:00
|
|
|
|
2017-01-17 04:12:26 +08:00
|
|
|
/// Originally, this function return hasISEL(). Now we always enable it,
|
|
|
|
/// but may expand the ISEL instruction later.
|
|
|
|
bool enableEarlyIfConversion() const override { return true; }
|
2014-05-22 07:40:26 +08:00
|
|
|
|
2019-06-12 01:40:39 +08:00
|
|
|
/// Scheduling customization.
|
2014-04-29 15:57:37 +08:00
|
|
|
bool enableMachineScheduler() const override;
|
2019-06-12 01:40:39 +08:00
|
|
|
/// Pipeliner customization.
|
|
|
|
bool enableMachinePipeliner() const override;
|
|
|
|
/// Machine Pipeliner customization
|
|
|
|
bool useDFAforSMS() const override;
|
|
|
|
/// This overrides the PostRAScheduler bit in the SchedModel for each CPU.
|
2015-06-13 11:42:16 +08:00
|
|
|
bool enablePostRAScheduler() const override;
|
2014-07-16 06:39:58 +08:00
|
|
|
AntiDepBreakMode getAntiDepBreakMode() const override;
|
|
|
|
void getCriticalPathRCs(RegClassVector &CriticalPathRCs) const override;
|
|
|
|
|
2013-09-12 07:05:25 +08:00
|
|
|
void overrideSchedPolicy(MachineSchedPolicy &Policy,
|
2014-04-29 15:57:37 +08:00
|
|
|
unsigned NumRegionInstrs) const override;
|
|
|
|
bool useAA() const override;
|
2015-01-09 10:03:11 +08:00
|
|
|
|
|
|
|
bool enableSubRegLiveness() const override;
|
2015-11-21 04:51:31 +08:00
|
|
|
|
2019-09-21 02:21:07 +08:00
|
|
|
/// True if the GV will be accessed via an indirect symbol.
|
|
|
|
bool isGVIndirectSymbol(const GlobalValue *GV) const;
|
[XRay] Implement powerpc64le xray.
Summary:
powerpc64 big-endian is not supported, but I believe that most logic can
be shared, except for xray_powerpc64.cc.
Also add a function InvalidateInstructionCache to xray_util.h, which is
copied from llvm/Support/Memory.cpp. I'm not sure if I need to add a unittest,
and I don't know how.
Reviewers: dberris, echristo, iteratee, kbarton, hfinkel
Subscribers: mehdi_amini, nemanjai, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29742
llvm-svn: 294781
2017-02-11 05:03:24 +08:00
|
|
|
|
2019-12-10 01:26:16 +08:00
|
|
|
/// True if the ABI is descriptor based.
|
|
|
|
bool usesFunctionDescriptors() const {
|
|
|
|
// Both 32-bit and 64-bit AIX are descriptor based. For ELF only the 64-bit
|
|
|
|
// v1 ABI uses descriptors.
|
|
|
|
return isAIXABI() || (is64BitELFABI() && !isELFv2ABI());
|
|
|
|
}
|
|
|
|
|
[PowerPC] Add Support for indirect calls on AIX.
Extends the desciptor-based indirect call support for 32-bit codegen,
and enables indirect calls for AIX.
In-depth Description:
In a function descriptor based ABI, a function pointer points at a
descriptor structure as opposed to the function's entry point. The
descriptor takes the form of 3 pointers: 1 for the function's entry
point, 1 for the TOC anchor of the module containing the function
definition, and 1 for the environment pointer:
struct FunctionDescriptor {
void *EntryPoint;
void *TOCAnchor;
void *EnvironmentPointer;
};
An indirect call has several steps of loading the the information from
the descriptor into the proper registers for setting up the call. Namely
it has to:
1) Save the caller's TOC pointer into the TOC save slot in the linkage
area, and then load the callee's TOC pointer into the TOC register
(GPR 2 on AIX).
2) Load the function descriptor's entry point into the count register.
3) Load the environment pointer into the environment pointer register
(GPR 11 on AIX).
4) Perform the call by branching on count register.
5) Restore the caller's TOC pointer after returning from the indirect call.
A couple important caveats to the above:
- There is no way to directly load a value from memory into the count register.
Instead we populate the count register by loading the entry point address into
a gpr and then moving the gpr to the count register.
- The TOC restore has to come immediately after the branch on count register
instruction (i.e., the 1st instruction executed after we return from the
call). This is an implementation limitation. We could, in theory, schedule
the restore elsewhere as long as no uses of the TOC pointer fall in between
the call and the restore; however, to keep it simple, we insert a pseudo
instruction that represents both the indirect branch instruction and the
load instruction that restores the caller's TOC from the linkage area. As
they flow through the compiler as a single pseudo instruction, nothing can be
inserted between them and the caller's TOC is then valid at any use.
Differtential Revision: https://reviews.llvm.org/D70724
2019-12-14 03:34:11 +08:00
|
|
|
unsigned descriptorTOCAnchorOffset() const {
|
|
|
|
assert(usesFunctionDescriptors() &&
|
|
|
|
"Should only be called when the target uses descriptors.");
|
|
|
|
return IsPPC64 ? 8 : 4;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned descriptorEnvironmentPointerOffset() const {
|
|
|
|
assert(usesFunctionDescriptors() &&
|
|
|
|
"Should only be called when the target uses descriptors.");
|
|
|
|
return IsPPC64 ? 16 : 8;
|
|
|
|
}
|
|
|
|
|
|
|
|
MCRegister getEnvironmentPointerRegister() const {
|
|
|
|
assert(usesFunctionDescriptors() &&
|
|
|
|
"Should only be called when the target uses descriptors.");
|
|
|
|
return IsPPC64 ? PPC::X11 : PPC::R11;
|
|
|
|
}
|
|
|
|
|
|
|
|
MCRegister getTOCPointerRegister() const {
|
|
|
|
assert((is64BitELFABI() || isAIXABI()) &&
|
|
|
|
"Should only be called when the target is a TOC based ABI.");
|
|
|
|
return IsPPC64 ? PPC::X2 : PPC::R2;
|
|
|
|
}
|
|
|
|
|
|
|
|
MCRegister getStackPointerRegister() const {
|
|
|
|
return IsPPC64 ? PPC::X1 : PPC::R1;
|
|
|
|
}
|
|
|
|
|
[XRay] Implement powerpc64le xray.
Summary:
powerpc64 big-endian is not supported, but I believe that most logic can
be shared, except for xray_powerpc64.cc.
Also add a function InvalidateInstructionCache to xray_util.h, which is
copied from llvm/Support/Memory.cpp. I'm not sure if I need to add a unittest,
and I don't know how.
Reviewers: dberris, echristo, iteratee, kbarton, hfinkel
Subscribers: mehdi_amini, nemanjai, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29742
llvm-svn: 294781
2017-02-11 05:03:24 +08:00
|
|
|
bool isXRaySupported() const override { return IsPPC64 && IsLittleEndian; }
|
2020-05-11 23:02:09 +08:00
|
|
|
|
|
|
|
bool isPredictableSelectIsExpensive() const {
|
|
|
|
return PredictableSelectIsExpensive;
|
|
|
|
}
|
2020-08-18 04:33:47 +08:00
|
|
|
|
2021-07-03 12:45:11 +08:00
|
|
|
// Select allocation orders of GPRC and G8RC. It should be strictly consistent
|
|
|
|
// with corresponding AltOrders in PPCRegisterInfo.td.
|
|
|
|
unsigned getGPRAllocationOrderIdx() const {
|
|
|
|
if (is64BitELFABI())
|
|
|
|
return 1;
|
|
|
|
if (isAIXABI())
|
|
|
|
return 2;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2020-08-18 04:33:47 +08:00
|
|
|
// GlobalISEL
|
|
|
|
const CallLowering *getCallLowering() const override;
|
|
|
|
const RegisterBankInfo *getRegBankInfo() const override;
|
|
|
|
const LegalizerInfo *getLegalizerInfo() const override;
|
|
|
|
InstructionSelector *getInstructionSelector() const override;
|
2005-08-04 15:12:09 +08:00
|
|
|
};
|
2015-06-23 17:49:53 +08:00
|
|
|
} // End llvm namespace
|
2005-08-04 15:12:09 +08:00
|
|
|
|
|
|
|
#endif
|