2012-02-18 12:03:15 +00:00
|
|
|
//===-- PPCSubtarget.h - Define Subtarget for the PPC ----------*- C++ -*--===//
|
2005-08-04 07:12:09 +00:00
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-29 20:36:04 +00:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2005-08-04 07:12:09 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2011-07-01 21:01:15 +00:00
|
|
|
// This file declares the PowerPC specific subclass of TargetSubtargetInfo.
|
2005-08-04 07:12:09 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef POWERPCSUBTARGET_H
|
|
|
|
#define POWERPCSUBTARGET_H
|
|
|
|
|
2014-06-12 20:54:11 +00:00
|
|
|
#include "PPCFrameLowering.h"
|
2014-06-12 22:05:46 +00:00
|
|
|
#include "PPCInstrInfo.h"
|
2014-06-12 22:50:10 +00:00
|
|
|
#include "PPCISelLowering.h"
|
2014-06-12 22:28:06 +00:00
|
|
|
#include "PPCJITInfo.h"
|
2014-06-12 23:02:32 +00:00
|
|
|
#include "PPCSelectionDAGInfo.h"
|
2011-06-29 01:14:12 +00:00
|
|
|
#include "llvm/ADT/Triple.h"
|
2014-06-12 21:08:06 +00:00
|
|
|
#include "llvm/IR/DataLayout.h"
|
2012-12-04 07:12:27 +00:00
|
|
|
#include "llvm/MC/MCInstrItineraries.h"
|
|
|
|
#include "llvm/Target/TargetSubtargetInfo.h"
|
2005-09-01 21:38:21 +00:00
|
|
|
#include <string>
|
|
|
|
|
2011-07-01 20:45:01 +00:00
|
|
|
#define GET_SUBTARGETINFO_HEADER
|
2011-07-01 22:36:09 +00:00
|
|
|
#include "PPCGenSubtargetInfo.inc"
|
2011-07-01 20:45:01 +00:00
|
|
|
|
2007-01-19 04:36:02 +00:00
|
|
|
// GCC #defines PPC on Linux but we use it as our namespace name
|
|
|
|
#undef PPC
|
|
|
|
|
2005-08-04 07:12:09 +00:00
|
|
|
namespace llvm {
|
2011-07-07 07:07:08 +00:00
|
|
|
class StringRef;
|
2006-12-12 20:57:08 +00:00
|
|
|
|
|
|
|
namespace PPC {
|
|
|
|
// -m directive values.
|
|
|
|
enum {
|
2008-02-14 23:35:16 +00:00
|
|
|
DIR_NONE,
|
2006-12-12 20:57:08 +00:00
|
|
|
DIR_32,
|
2012-10-29 15:51:35 +00:00
|
|
|
DIR_440,
|
|
|
|
DIR_601,
|
|
|
|
DIR_602,
|
|
|
|
DIR_603,
|
2006-12-12 20:57:08 +00:00
|
|
|
DIR_7400,
|
2012-10-29 15:51:35 +00:00
|
|
|
DIR_750,
|
|
|
|
DIR_970,
|
2012-04-01 19:22:40 +00:00
|
|
|
DIR_A2,
|
2012-08-28 16:12:39 +00:00
|
|
|
DIR_E500mc,
|
|
|
|
DIR_E5500,
|
2013-02-01 22:59:51 +00:00
|
|
|
DIR_PWR3,
|
|
|
|
DIR_PWR4,
|
|
|
|
DIR_PWR5,
|
|
|
|
DIR_PWR5X,
|
2012-06-11 15:43:08 +00:00
|
|
|
DIR_PWR6,
|
2013-02-01 22:59:51 +00:00
|
|
|
DIR_PWR6X,
|
2012-06-11 15:43:08 +00:00
|
|
|
DIR_PWR7,
|
2014-06-26 13:36:19 +00:00
|
|
|
DIR_PWR8,
|
2012-10-29 15:51:35 +00:00
|
|
|
DIR_64
|
2006-12-12 20:57:08 +00:00
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2006-12-11 23:22:45 +00:00
|
|
|
class GlobalValue;
|
|
|
|
class TargetMachine;
|
2012-10-29 15:51:35 +00:00
|
|
|
|
2011-07-01 20:45:01 +00:00
|
|
|
class PPCSubtarget : public PPCGenSubtargetInfo {
|
2005-08-04 07:12:09 +00:00
|
|
|
protected:
|
|
|
|
/// stackAlignment - The minimum alignment known to hold of the stack frame on
|
|
|
|
/// entry to the function and which must be maintained by every function.
|
2005-08-05 22:05:03 +00:00
|
|
|
unsigned StackAlignment;
|
2012-10-29 15:51:35 +00:00
|
|
|
|
2005-11-01 20:06:59 +00:00
|
|
|
/// Selected instruction itineraries (one entry per itinerary class.)
|
|
|
|
InstrItineraryData InstrItins;
|
2012-10-29 15:51:35 +00:00
|
|
|
|
2006-12-12 20:57:08 +00:00
|
|
|
/// Which cpu directive was used.
|
|
|
|
unsigned DarwinDirective;
|
2005-08-04 07:12:09 +00:00
|
|
|
|
|
|
|
/// Used by the ISel to turn in optimizations for POWER4-derived architectures
|
2012-06-11 19:57:01 +00:00
|
|
|
bool HasMFOCRF;
|
2006-06-16 17:34:12 +00: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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202451 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-28 00:27:01 +00:00
|
|
|
bool UseCRBits;
|
2006-06-16 17:50:12 +00:00
|
|
|
bool IsPPC64;
|
2005-10-26 17:30:34 +00:00
|
|
|
bool HasAltivec;
|
2013-01-30 21:17:42 +00:00
|
|
|
bool HasQPX;
|
2013-10-16 20:38:58 +00:00
|
|
|
bool HasVSX;
|
2013-08-19 05:01:02 +00:00
|
|
|
bool HasFCPSGN;
|
2005-09-02 18:33:05 +00:00
|
|
|
bool HasFSQRT;
|
2013-04-03 04:01:11 +00:00
|
|
|
bool HasFRE, HasFRES, HasFRSQRTE, HasFRSQRTES;
|
|
|
|
bool HasRecipPrec;
|
2006-02-28 07:08:22 +00:00
|
|
|
bool HasSTFIWX;
|
2013-03-31 10:12:51 +00:00
|
|
|
bool HasLFIWAX;
|
2013-03-29 08:57:48 +00:00
|
|
|
bool HasFPRND;
|
2013-04-01 17:52:07 +00:00
|
|
|
bool HasFPCVT;
|
2012-06-22 23:10:08 +00:00
|
|
|
bool HasISEL;
|
2013-03-28 13:29:47 +00:00
|
|
|
bool HasPOPCNTD;
|
2013-03-28 19:25:55 +00:00
|
|
|
bool HasLDBRX;
|
2011-10-17 04:03:49 +00:00
|
|
|
bool IsBookE;
|
2013-09-12 14:40:06 +00:00
|
|
|
bool DeprecatedMFTB;
|
|
|
|
bool DeprecatedDST;
|
2006-12-11 23:22:45 +00:00
|
|
|
bool HasLazyResolverStubs;
|
2010-08-04 20:47:44 +00:00
|
|
|
bool IsJITCodeModel;
|
2013-07-26 01:35:43 +00:00
|
|
|
bool IsLittleEndian;
|
2012-10-29 15:51:35 +00:00
|
|
|
|
2011-04-19 20:54:28 +00:00
|
|
|
/// TargetTriple - What processor and OS we're targeting.
|
|
|
|
Triple TargetTriple;
|
|
|
|
|
2014-05-13 20:49:08 +00:00
|
|
|
/// OptLevel - What default optimization level we're emitting code for.
|
|
|
|
CodeGenOpt::Level OptLevel;
|
|
|
|
|
2014-06-12 22:28:06 +00:00
|
|
|
PPCFrameLowering FrameLowering;
|
2014-06-12 21:08:06 +00:00
|
|
|
const DataLayout DL;
|
2014-06-12 22:05:46 +00:00
|
|
|
PPCInstrInfo InstrInfo;
|
2014-06-12 22:28:06 +00:00
|
|
|
PPCJITInfo JITInfo;
|
2014-06-12 22:50:10 +00:00
|
|
|
PPCTargetLowering TLInfo;
|
2014-06-12 23:02:32 +00:00
|
|
|
PPCSelectionDAGInfo TSInfo;
|
2014-06-12 21:08:06 +00:00
|
|
|
|
2005-08-04 07:12:09 +00:00
|
|
|
public:
|
|
|
|
/// This constructor initializes the data members to match that
|
2009-08-02 22:11:08 +00:00
|
|
|
/// of the specified triple.
|
2005-08-04 07:12:09 +00:00
|
|
|
///
|
2011-06-30 01:53:36 +00:00
|
|
|
PPCSubtarget(const std::string &TT, const std::string &CPU,
|
2014-06-12 22:50:10 +00:00
|
|
|
const std::string &FS, PPCTargetMachine &TM, bool is64Bit,
|
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202451 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-28 00:27:01 +00:00
|
|
|
CodeGenOpt::Level OptLevel);
|
2012-10-29 15:51:35 +00:00
|
|
|
|
|
|
|
/// ParseSubtargetFeatures - Parses features string setting specified
|
2005-10-26 18:07:50 +00:00
|
|
|
/// subtarget options. Definition of function is auto generated by tblgen.
|
2011-07-07 07:07:08 +00:00
|
|
|
void ParseSubtargetFeatures(StringRef CPU, StringRef FS);
|
2012-10-29 15:51:35 +00:00
|
|
|
|
2006-12-11 23:22:45 +00:00
|
|
|
/// SetJITMode - This is called to inform the subtarget info that we are
|
|
|
|
/// producing code for the JIT.
|
|
|
|
void SetJITMode();
|
2005-08-04 07:12:09 +00: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.
|
2005-08-05 22:05:03 +00:00
|
|
|
unsigned getStackAlignment() const { return StackAlignment; }
|
2012-10-29 15:51:35 +00:00
|
|
|
|
2006-12-12 20:57:08 +00:00
|
|
|
/// getDarwinDirective - Returns the -m directive specified for the cpu.
|
|
|
|
///
|
|
|
|
unsigned getDarwinDirective() const { return DarwinDirective; }
|
2012-10-29 15:51:35 +00:00
|
|
|
|
2014-06-13 22:38:48 +00:00
|
|
|
/// getInstrItins - Return the instruction itineraries based on subtarget
|
2005-11-01 20:06:59 +00:00
|
|
|
/// selection.
|
2006-12-11 21:42:55 +00:00
|
|
|
const InstrItineraryData &getInstrItineraryData() const { return InstrItins; }
|
2006-06-16 17:50:12 +00:00
|
|
|
|
2014-06-12 20:54:11 +00:00
|
|
|
const PPCFrameLowering *getFrameLowering() const { return &FrameLowering; }
|
2014-06-12 21:08:06 +00:00
|
|
|
const DataLayout *getDataLayout() const { return &DL; }
|
2014-06-12 22:05:46 +00:00
|
|
|
const PPCInstrInfo *getInstrInfo() const { return &InstrInfo; }
|
2014-06-12 22:28:06 +00:00
|
|
|
PPCJITInfo *getJITInfo() { return &JITInfo; }
|
2014-06-12 22:50:10 +00:00
|
|
|
const PPCTargetLowering *getTargetLowering() const { return &TLInfo; }
|
2014-06-12 23:02:32 +00:00
|
|
|
const PPCSelectionDAGInfo *getSelectionDAGInfo() const { return &TSInfo; }
|
2014-06-12 20:54:11 +00: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-15 22:29:40 +00:00
|
|
|
/// \brief Reset the features for the PowerPC target.
|
2014-04-29 07:57:37 +00:00
|
|
|
void resetSubtargetFeatures(const MachineFunction *MF) override;
|
2013-07-15 22:29:40 +00:00
|
|
|
private:
|
|
|
|
void initializeEnvironment();
|
|
|
|
void resetSubtargetFeatures(StringRef CPU, StringRef FS);
|
|
|
|
|
|
|
|
public:
|
2006-06-16 17:50:12 +00:00
|
|
|
/// isPPC64 - Return true if we are generating code for 64-bit pointer mode.
|
|
|
|
///
|
|
|
|
bool isPPC64() const { return IsPPC64; }
|
2012-10-29 15:51:35 +00:00
|
|
|
|
2006-06-16 17:50:12 +00: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; }
|
2012-10-29 15:51:35 +00:00
|
|
|
|
2006-06-16 17:50:12 +00: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 15:51:35 +00: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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202451 91177308-0d34-0410-b5e6-96231b3b80d8
2014-02-28 00:27:01 +00:00
|
|
|
/// useCRBits - Return true if we should store and manipulate i1 values in
|
|
|
|
/// the individual condition register bits.
|
|
|
|
bool useCRBits() const { return UseCRBits; }
|
|
|
|
|
2006-12-11 23:22:45 +00:00
|
|
|
/// hasLazyResolverStub - 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.
|
2012-10-29 15:51:35 +00:00
|
|
|
bool hasLazyResolverStub(const GlobalValue *GV,
|
2009-08-02 22:11:08 +00:00
|
|
|
const TargetMachine &TM) const;
|
2012-10-29 15:51:35 +00:00
|
|
|
|
2010-08-04 20:47:44 +00:00
|
|
|
// isJITCodeModel - True if we're generating code for the JIT
|
|
|
|
bool isJITCodeModel() const { return IsJITCodeModel; }
|
|
|
|
|
2013-07-26 01:35:43 +00:00
|
|
|
// isLittleEndian - True if generating little-endian code
|
|
|
|
bool isLittleEndian() const { return IsLittleEndian; }
|
|
|
|
|
2006-06-16 17:50:12 +00:00
|
|
|
// Specific obvious features.
|
2013-08-19 05:01:02 +00:00
|
|
|
bool hasFCPSGN() const { return HasFCPSGN; }
|
2005-09-02 18:33:05 +00:00
|
|
|
bool hasFSQRT() const { return HasFSQRT; }
|
2013-04-03 04:01:11 +00: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 07:08:22 +00:00
|
|
|
bool hasSTFIWX() const { return HasSTFIWX; }
|
2013-03-31 10:12:51 +00:00
|
|
|
bool hasLFIWAX() const { return HasLFIWAX; }
|
2013-03-29 08:57:48 +00:00
|
|
|
bool hasFPRND() const { return HasFPRND; }
|
2013-04-01 17:52:07 +00:00
|
|
|
bool hasFPCVT() const { return HasFPCVT; }
|
2005-10-26 17:30:34 +00:00
|
|
|
bool hasAltivec() const { return HasAltivec; }
|
2013-01-30 21:17:42 +00:00
|
|
|
bool hasQPX() const { return HasQPX; }
|
[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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203768 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-13 07:58:58 +00:00
|
|
|
bool hasVSX() const { return HasVSX; }
|
2012-06-11 19:57:01 +00:00
|
|
|
bool hasMFOCRF() const { return HasMFOCRF; }
|
2012-06-22 23:10:08 +00:00
|
|
|
bool hasISEL() const { return HasISEL; }
|
2013-03-28 13:29:47 +00:00
|
|
|
bool hasPOPCNTD() const { return HasPOPCNTD; }
|
2013-03-28 19:25:55 +00:00
|
|
|
bool hasLDBRX() const { return HasLDBRX; }
|
2011-10-17 04:03:49 +00:00
|
|
|
bool isBookE() const { return IsBookE; }
|
2013-09-12 14:40:06 +00:00
|
|
|
bool isDeprecatedMFTB() const { return DeprecatedMFTB; }
|
|
|
|
bool isDeprecatedDST() const { return DeprecatedDST; }
|
2007-01-16 09:29:17 +00:00
|
|
|
|
2011-04-19 20:54:28 +00:00
|
|
|
const Triple &getTargetTriple() const { return TargetTriple; }
|
|
|
|
|
2008-01-02 19:35:16 +00:00
|
|
|
/// isDarwin - True if this is any darwin platform.
|
2011-04-20 00:14:25 +00:00
|
|
|
bool isDarwin() const { return TargetTriple.isMacOSX(); }
|
2013-01-29 00:22:47 +00:00
|
|
|
/// isBGQ - True if this is a BG/Q platform.
|
|
|
|
bool isBGQ() const { return TargetTriple.getVendor() == Triple::BGQ; }
|
2008-12-19 10:55:56 +00:00
|
|
|
|
2014-07-18 23:29:49 +00:00
|
|
|
bool isTargetELF() const { return TargetTriple.isOSBinFormatELF(); }
|
|
|
|
bool isTargetMachO() const { return TargetTriple.isOSBinFormatMachO(); }
|
|
|
|
|
2009-08-15 11:54:46 +00:00
|
|
|
bool isDarwinABI() const { return isDarwin(); }
|
|
|
|
bool isSVR4ABI() const { return !isDarwin(); }
|
[PowerPC] ELFv2 function call changes
This patch builds upon the two preceding MC changes to implement the
basic ELFv2 function call convention. In the ELFv1 ABI, a "function
descriptor" was associated with every function, pointing to both the
entry address and the related TOC base (and a static chain pointer
for nested functions). Function pointers would actually refer to that
descriptor, and the indirect call sequence needed to load up both entry
address and TOC base.
In the ELFv2 ABI, there are no more function descriptors, and function
pointers simply refer to the (global) entry point of the function code.
Indirect function calls simply branch to that address, after loading it
up into r12 (as required by the ABI rules for a global entry point).
Direct function calls continue to just do a "bl" to the target symbol;
this will be resolved by the linker to the local entry point of the
target function if it is local, and to a PLT stub if it is global.
That PLT stub would then load the (global) entry point address of the
final target into r12 and branch to it. Note that when performing a
local function call, r2 must be set up to point to the current TOC
base: if the target ends up local, the ABI requires that its local
entry point is called with r2 set up; if the target ends up global,
the PLT stub requires that r2 is set up.
This patch implements all LLVM changes to implement that scheme:
- No longer create a function descriptor when emitting a function
definition (in EmitFunctionEntryLabel)
- Emit two entry points *if* the function needs the TOC base (r2)
anywhere (this is done EmitFunctionBodyStart; note that this cannot
be done in EmitFunctionBodyStart because the global entry point
prologue code must be *part* of the function as covered by debug info).
- In order to make use tracking of r2 (as needed above) work correctly,
mark direct function calls as implicitly using r2.
- Implement the ELFv2 indirect function call sequence (no function
descriptors; load target address into r12).
- When creating an ELFv2 object file, emit the .abiversion 2 directive
to tell the linker to create the appropriate version of PLT stubs.
Reviewed by Hal Finkel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213489 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-20 23:31:44 +00:00
|
|
|
/// FIXME: Should use a command-line option.
|
|
|
|
bool isELFv2ABI() const { return isPPC64() && isSVR4ABI() &&
|
|
|
|
isLittleEndian(); }
|
2009-08-15 11:54:46 +00:00
|
|
|
|
2014-05-21 23:40:26 +00:00
|
|
|
bool enableEarlyIfConversion() const override { return hasISEL(); }
|
|
|
|
|
2013-09-11 23:05:25 +00:00
|
|
|
// Scheduling customization.
|
2014-04-29 07:57:37 +00:00
|
|
|
bool enableMachineScheduler() const override;
|
2014-07-15 22:39:58 +00:00
|
|
|
// This overrides the PostRAScheduler bit in the SchedModel for each CPU.
|
|
|
|
bool enablePostMachineScheduler() const override;
|
|
|
|
AntiDepBreakMode getAntiDepBreakMode() const override;
|
|
|
|
void getCriticalPathRCs(RegClassVector &CriticalPathRCs) const override;
|
|
|
|
|
2013-09-11 23:05:25 +00:00
|
|
|
void overrideSchedPolicy(MachineSchedPolicy &Policy,
|
|
|
|
MachineInstr *begin,
|
|
|
|
MachineInstr *end,
|
2014-04-29 07:57:37 +00:00
|
|
|
unsigned NumRegionInstrs) const override;
|
|
|
|
bool useAA() const override;
|
2005-08-04 07:12:09 +00:00
|
|
|
};
|
|
|
|
} // End llvm namespace
|
|
|
|
|
|
|
|
#endif
|