maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Target/PowerPC/PPC.td

335 lines
17 KiB
TableGen
Raw Normal View History

Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, MSP430, PPC, PTX, Sparc, X86, XCore. llvm-svn: 150878
2012-02-18 20:03:15 +08:00
//===-- PPC.td - Describe the PowerPC Target Machine -------*- tablegen -*-===//
//
Eliminate PowerPC.td and PPC32.td, consolidating them into PPC.td llvm-svn: 23738
2005-10-15 07:37:35 +08:00
// The LLVM Compiler Infrastructure
//
Remove attribution from file headers, per discussion on llvmdev. llvm-svn: 45418
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.
Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, MSP430, PPC, PTX, Sparc, X86, XCore. llvm-svn: 150878
2012-02-18 20:03:15 +08:00
//
Eliminate PowerPC.td and PPC32.td, consolidating them into PPC.td llvm-svn: 23738
2005-10-15 07:37:35 +08:00
//===----------------------------------------------------------------------===//
//
// This is the top level entry point for the PowerPC target.
//
//===----------------------------------------------------------------------===//
// Get the target-independent interfaces which we are implementing.
//
Move target independent td files from lib/Target/ to include/llvm/Target so they can be distributed along with the header files. llvm-svn: 59953
2008-11-24 15:34:46 +08:00
include "llvm/Target/Target.td"
Eliminate PowerPC.td and PPC32.td, consolidating them into PPC.td llvm-svn: 23738
2005-10-15 07:37:35 +08:00
Added InstrSchedClass to each of the PowerPC Instructions. Note that when adding new instructions that you should refer to the table at the bottom of PPCSchedule.td. llvm-svn: 23830
2005-10-20 03:51:16 +08:00
//===----------------------------------------------------------------------===//
Add g3 back to the mix and reorder to irritate them anal folk. Actually, it's to group appropriately and provide cues to maintainers that the lists don't need to be ordered. llvm-svn: 23880
2005-10-22 16:04:24 +08:00
// PowerPC Subtarget features.
Added InstrSchedClass to each of the PowerPC Instructions. Note that when adding new instructions that you should refer to the table at the bottom of PPCSchedule.td. llvm-svn: 23830
2005-10-20 03:51:16 +08:00
//
Honor cpu directive, take two. llvm-svn: 32492
2006-12-13 04:57:08 +08:00
//===----------------------------------------------------------------------===//
// CPU Directives //
//===----------------------------------------------------------------------===//
Add PPC 440 scheduler and some associated tests llvm-svn: 142170
2011-10-17 12:03:49 +08:00
def Directive440 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_440", "">;
Honor cpu directive, take two. llvm-svn: 32492
2006-12-13 04:57:08 +08:00
def Directive601 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_601", "">;
def Directive602 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_602", "">;
def Directive603 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_603", "">;
def Directive604 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_603", "">;
def Directive620 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_603", "">;
def Directive7400: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_7400", "">;
def Directive750 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_750", "">;
def Directive970 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_970", "">;
def Directive32 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_32", "">;
def Directive64 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_64", "">;
Add instruction itinerary for the PPC64 A2 core. This adds a full itinerary for IBM's PPC64 A2 embedded core. These cores form the basis for the CPUs in the new IBM BG/Q supercomputer. llvm-svn: 153842
2012-04-02 03:22:40 +08:00
def DirectiveA2 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_A2", "">;
Add PPC Freescale e500mc and e5500 subtargets. Add subtargets for Freescale e500mc (32-bit) and e5500 (64-bit) to the PowerPC backend. Patch by Tobias von Koch. llvm-svn: 162764
2012-08-29 00:12:39 +08:00
def DirectiveE500mc : SubtargetFeature<"", "DarwinDirective",
"PPC::DIR_E500mc", "">;
def DirectiveE5500 : SubtargetFeature<"", "DarwinDirective",
"PPC::DIR_E5500", "">;
LLVM enablement for some older PowerPC CPUs llvm-svn: 174230
2013-02-02 06:59:51 +08:00
def DirectivePwr3: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR3", "">;
def DirectivePwr4: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR4", "">;
def DirectivePwr5: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR5", "">;
def DirectivePwr5x: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR5X", "">;
Add POWER6 and POWER7 CPU types to the PPC backend. No functional change; these will be used by upcoming scheduler enhancements. llvm-svn: 158313
2012-06-11 23:43:08 +08:00
def DirectivePwr6: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR6", "">;
LLVM enablement for some older PowerPC CPUs llvm-svn: 174230
2013-02-02 06:59:51 +08:00
def DirectivePwr6x: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR6X", "">;
Add POWER6 and POWER7 CPU types to the PPC backend. No functional change; these will be used by upcoming scheduler enhancements. llvm-svn: 158313
2012-06-11 23:43:08 +08:00
def DirectivePwr7: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR7", "">;
Honor cpu directive, take two. llvm-svn: 32492
2006-12-13 04:57:08 +08:00
Rename some subtarget features. A CPU now can *have* 64-bit instructions, can in 32-bit mode we can choose to optionally *use* 64-bit registers. llvm-svn: 28824
2006-06-17 01:34:12 +08:00
def Feature64Bit : SubtargetFeature<"64bit","Has64BitSupport", "true",
improve -help output llvm-svn: 23892
2005-10-23 13:28:51 +08:00
"Enable 64-bit instructions">;
Rename some subtarget features. A CPU now can *have* 64-bit instructions, can in 32-bit mode we can choose to optionally *use* 64-bit registers. llvm-svn: 28824
2006-06-17 01:34:12 +08:00
def Feature64BitRegs : SubtargetFeature<"64bitregs","Use64BitRegs", "true",
"Enable 64-bit registers usage for ppc32 [beta]">;
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
def FeatureCRBits : SubtargetFeature<"crbits", "UseCRBits", "true",
"Use condition-register bits individually">;
Subtarget feature can now set any variable to any value llvm-svn: 25678
2006-01-27 16:09:42 +08:00
def FeatureAltivec : SubtargetFeature<"altivec","HasAltivec", "true",
improve -help output llvm-svn: 23892
2005-10-23 13:28:51 +08:00
"Enable Altivec instructions">;
Rename the PPC target feature gpul to mfocrf. The PPC target feature gpul (IsGigaProcessor) was only used for one thing: To enable the generation of the MFOCRF instruction. Furthermore, this instruction is available on other PPC cores outside of the G5 line. This feature now corresponds to the HasMFOCRF flag. No functionality change. llvm-svn: 158323
2012-06-12 03:57:01 +08:00
def FeatureMFOCRF : SubtargetFeature<"mfocrf","HasMFOCRF", "true",
"Enable the MFOCRF instruction">;
Subtarget feature can now set any variable to any value llvm-svn: 25678
2006-01-27 16:09:42 +08:00
def FeatureFSqrt : SubtargetFeature<"fsqrt","HasFSQRT", "true",
initial test commit (remove whitespace) llvm-svn: 141972
2011-10-15 02:54:13 +08:00
"Enable the fsqrt instruction">;
Add the PPC fcpsgn instruction Modern PPC cores support a floating-point copysign instruction, and we can use this to lower the FCOPYSIGN node (which is created from calls to the libm copysign function). A couple of extra patterns are necessary because the operand types of FCOPYSIGN need not agree. llvm-svn: 188653
2013-08-19 13:01:02 +08:00
def FeatureFCPSGN : SubtargetFeature<"fcpsgn", "HasFCPSGN", "true",
"Enable the fcpsgn instruction">;
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
def FeatureFRE : SubtargetFeature<"fre", "HasFRE", "true",
"Enable the fre instruction">;
def FeatureFRES : SubtargetFeature<"fres", "HasFRES", "true",
"Enable the fres instruction">;
def FeatureFRSQRTE : SubtargetFeature<"frsqrte", "HasFRSQRTE", "true",
"Enable the frsqrte instruction">;
def FeatureFRSQRTES : SubtargetFeature<"frsqrtes", "HasFRSQRTES", "true",
"Enable the frsqrtes instruction">;
def FeatureRecipPrec : SubtargetFeature<"recipprec", "HasRecipPrec", "true",
"Assume higher precision reciprocal estimates">;
Add a subtarget feature for the stfiwx instruction. I know the G5 has it, but I don't know what other PPC impls do. If someone could update the proc table, I would appreciate it :) llvm-svn: 26421
2006-02-28 15:08:22 +08:00
def FeatureSTFIWX : SubtargetFeature<"stfiwx","HasSTFIWX", "true",
initial test commit (remove whitespace) llvm-svn: 141972
2011-10-15 02:54:13 +08:00
"Enable the stfiwx instruction">;
Add the PPC lfiwax instruction This instruction is available on modern PPC64 CPUs, and is now used to improve the SINT_TO_FP lowering (by eliminating the need for the separate sign extension instruction and decreasing the amount of needed stack space). llvm-svn: 178446
2013-03-31 18:12:51 +08:00
def FeatureLFIWAX : SubtargetFeature<"lfiwax","HasLFIWAX", "true",
"Enable the lfiwax instruction">;
Add PPC FP rounding instructions fri[mnpz] These instructions are available on the P5x (and later) and on the A2. They implement the standard floating-point rounding operations (floor, trunc, etc.). One caveat: frin (round to nearest) does not implement "ties to even", and so is only enabled in fast-math mode. llvm-svn: 178337
2013-03-29 16:57:48 +08:00
def FeatureFPRND : SubtargetFeature<"fprnd", "HasFPRND", "true",
"Enable the fri[mnpz] instructions">;
Add more PPC floating-point conversion instructions The P7 and A2 have additional floating-point conversion instructions which allow a direct two-instruction sequence (plus load/store) to convert from all combinations (signed/unsigned i32/i64) <--> (float/double) (on previous cores, only some combinations were directly available). llvm-svn: 178480
2013-04-02 01:52:07 +08:00
def FeatureFPCVT : SubtargetFeature<"fpcvt", "HasFPCVT", "true",
"Enable fc[ft]* (unsigned and single-precision) and lfiwzx instructions">;
Add support for the PPC isel instruction. The isel (integer select) instruction is supported on the 440 and A2 embedded cores and on the POWER7. llvm-svn: 159045
2012-06-23 07:10:08 +08:00
def FeatureISEL : SubtargetFeature<"isel","HasISEL", "true",
"Enable the isel instruction">;
Add the PPC64 popcntd instruction PPC ISA 2.06 (P7, A2, etc.) has a popcntd instruction. Add this instruction and tell TTI about it so that popcount-loop recognition will know about it. llvm-svn: 178233
2013-03-28 21:29:47 +08:00
def FeaturePOPCNTD : SubtargetFeature<"popcntd","HasPOPCNTD", "true",
"Enable the popcnt[dw] instructions">;
Add the PPC64 ldbrx/stdbrx instructions These are 64-bit load/store with byte-swap, and available on the P7 and the A2. Like the similar instructions for 16- and 32-bit words, these are matched in the target DAG-combine phase against load/store-bswap pairs. llvm-svn: 178276
2013-03-29 03:25:55 +08:00
def FeatureLDBRX : SubtargetFeature<"ldbrx","HasLDBRX", "true",
"Enable the ldbrx instruction">;
Add PPC 440 scheduler and some associated tests llvm-svn: 142170
2011-10-17 12:03:49 +08:00
def FeatureBookE : SubtargetFeature<"booke", "IsBookE", "true",
"Enable Book E instructions">;
Add definitions for the PPC a2q core marked as having QPX available This is the first commit of a large series which will add support for the QPX vector instruction set to the PowerPC backend. This instruction set is used on the IBM Blue Gene/Q supercomputers. llvm-svn: 173973
2013-01-31 05:17:42 +08:00
def FeatureQPX : SubtargetFeature<"qpx","HasQPX", "true",
"Enable QPX instructions">;
Add support for the VSX target attribute. No functional change as we don't actually use it to emit any code yet. llvm-svn: 192837
2013-10-17 04:38:58 +08:00
def FeatureVSX : SubtargetFeature<"vsx","HasVSX", "true",
[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
"Enable VSX instructions",
[FeatureAltivec]>;
Added InstrSchedClass to each of the PowerPC Instructions. Note that when adding new instructions that you should refer to the table at the bottom of PPCSchedule.td. llvm-svn: 23830
2005-10-20 03:51:16 +08:00
Mark PPC MFTB and DST (and friends) as deprecated Use the new instruction deprecation feature to mark mftb (now replaced with mfspr) and dst (along with the other Altivec cache control instructions) as deprecated when targeting cores supporting at least ISA v2.03. llvm-svn: 190605
2013-09-12 22:40:06 +08:00
def DeprecatedMFTB : SubtargetFeature<"", "DeprecatedMFTB", "true",
"Treat mftb as deprecated">;
def DeprecatedDST : SubtargetFeature<"", "DeprecatedDST", "true",
"Treat vector data stream cache control instructions as deprecated">;
Add notes about future PowerPC features llvm-svn: 174232
2013-02-02 07:10:09 +08:00
// Note: Future features to add when support is extended to more
// recent ISA levels:
//
// CMPB p6, p6x, p7 cmpb
// DFP p6, p6x, p7 decimal floating-point instructions
// POPCNTB p5 through p7 popcntb and related instructions
// VSX p7 vector-scalar instruction set
Add PPC instruction record forms and associated query functions This is prep. work for the implementation of optimizeCompare. Many PPC instructions have 'record' forms (in almost all cases, this means that the RC bit is set) that cause the result of the instruction to be compared with zero, and the result of that comparison saved in a predefined condition register. In order to add the record forms of the instructions without too much copy-and-paste, the relevant functions have been refactored into multiclasses which define both the record and normal forms. Also, two TableGen-generated mapping functions have been added which allow querying the instruction code for the record form given the normal form (and vice versa). No functionality change intended. llvm-svn: 179356
2013-04-12 10:18:09 +08:00
//===----------------------------------------------------------------------===//
// Classes used for relation maps.
//===----------------------------------------------------------------------===//
// RecFormRel - Filter class used to relate non-record-form instructions with
// their record-form variants.
class RecFormRel;
[PowerPC] Add a TableGen relation for A-type and M-type VSX FMA instructions TableGen will create a lookup table for the A-type FMA instructions providing their corresponding M-form opcodes. This will be used by upcoming commits. llvm-svn: 204746
2014-03-26 02:55:11 +08:00
// AltVSXFMARel - Filter class used to relate the primary addend-killing VSX
// FMA instruction forms with their corresponding factor-killing forms.
class AltVSXFMARel {
bit IsVSXFMAAlt = 0;
}
Add PPC instruction record forms and associated query functions This is prep. work for the implementation of optimizeCompare. Many PPC instructions have 'record' forms (in almost all cases, this means that the RC bit is set) that cause the result of the instruction to be compared with zero, and the result of that comparison saved in a predefined condition register. In order to add the record forms of the instructions without too much copy-and-paste, the relevant functions have been refactored into multiclasses which define both the record and normal forms. Also, two TableGen-generated mapping functions have been added which allow querying the instruction code for the record form given the normal form (and vice versa). No functionality change intended. llvm-svn: 179356
2013-04-12 10:18:09 +08:00
//===----------------------------------------------------------------------===//
// Relation Map Definitions.
//===----------------------------------------------------------------------===//
def getRecordFormOpcode : InstrMapping {
let FilterClass = "RecFormRel";
// Instructions with the same BaseName and Interpretation64Bit values
// form a row.
let RowFields = ["BaseName", "Interpretation64Bit"];
// Instructions with the same RC value form a column.
let ColFields = ["RC"];
// The key column are the non-record-form instructions.
let KeyCol = ["0"];
// Value columns RC=1
let ValueCols = [["1"]];
}
def getNonRecordFormOpcode : InstrMapping {
let FilterClass = "RecFormRel";
// Instructions with the same BaseName and Interpretation64Bit values
// form a row.
let RowFields = ["BaseName", "Interpretation64Bit"];
// Instructions with the same RC value form a column.
let ColFields = ["RC"];
// The key column are the record-form instructions.
let KeyCol = ["1"];
// Value columns are RC=0
let ValueCols = [["0"]];
}
[PowerPC] Add a TableGen relation for A-type and M-type VSX FMA instructions TableGen will create a lookup table for the A-type FMA instructions providing their corresponding M-form opcodes. This will be used by upcoming commits. llvm-svn: 204746
2014-03-26 02:55:11 +08:00
def getAltVSXFMAOpcode : InstrMapping {
let FilterClass = "AltVSXFMARel";
// Instructions with the same BaseName and Interpretation64Bit values
// form a row.
let RowFields = ["BaseName"];
// Instructions with the same RC value form a column.
let ColFields = ["IsVSXFMAAlt"];
// The key column are the (default) addend-killing instructions.
let KeyCol = ["0"];
// Value columns IsVSXFMAAlt=1
let ValueCols = [["1"]];
}
Added InstrSchedClass to each of the PowerPC Instructions. Note that when adding new instructions that you should refer to the table at the bottom of PPCSchedule.td. llvm-svn: 23830
2005-10-20 03:51:16 +08:00
//===----------------------------------------------------------------------===//
rearrange things a bit so that instructions can use subtarget features in the future. llvm-svn: 23902
2005-10-24 06:08:13 +08:00
// Register File Description
//===----------------------------------------------------------------------===//
include "PPCRegisterInfo.td"
include "PPCSchedule.td"
include "PPCInstrInfo.td"
//===----------------------------------------------------------------------===//
// PowerPC processors supported.
Added InstrSchedClass to each of the PowerPC Instructions. Note that when adding new instructions that you should refer to the table at the bottom of PPCSchedule.td. llvm-svn: 23830
2005-10-20 03:51:16 +08:00
//
Honor cpu directive, take two. llvm-svn: 32492
2006-12-13 04:57:08 +08:00
def : Processor<"generic", G3Itineraries, [Directive32]>;
Create a PPC440 SchedMachineModel Some of the older PPC processor definitions don't have associated SchedMachineModels; correct this for the PPC440. llvm-svn: 195949
2013-11-29 14:32:17 +08:00
def : ProcessorModel<"440", PPC440Model, [Directive440, FeatureISEL,
FeatureFRES, FeatureFRSQRTE,
FeatureBookE, DeprecatedMFTB]>;
def : ProcessorModel<"450", PPC440Model, [Directive440, FeatureISEL,
FeatureFRES, FeatureFRSQRTE,
FeatureBookE, DeprecatedMFTB]>;
Honor cpu directive, take two. llvm-svn: 32492
2006-12-13 04:57:08 +08:00
def : Processor<"601", G3Itineraries, [Directive601]>;
def : Processor<"602", G3Itineraries, [Directive602]>;
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
def : Processor<"603", G3Itineraries, [Directive603,
FeatureFRES, FeatureFRSQRTE]>;
def : Processor<"603e", G3Itineraries, [Directive603,
FeatureFRES, FeatureFRSQRTE]>;
def : Processor<"603ev", G3Itineraries, [Directive603,
FeatureFRES, FeatureFRSQRTE]>;
def : Processor<"604", G3Itineraries, [Directive604,
FeatureFRES, FeatureFRSQRTE]>;
def : Processor<"604e", G3Itineraries, [Directive604,
FeatureFRES, FeatureFRSQRTE]>;
def : Processor<"620", G3Itineraries, [Directive620,
FeatureFRES, FeatureFRSQRTE]>;
def : Processor<"750", G4Itineraries, [Directive750,
FeatureFRES, FeatureFRSQRTE]>;
def : Processor<"g3", G3Itineraries, [Directive750,
FeatureFRES, FeatureFRSQRTE]>;
def : Processor<"7400", G4Itineraries, [Directive7400, FeatureAltivec,
FeatureFRES, FeatureFRSQRTE]>;
def : Processor<"g4", G4Itineraries, [Directive7400, FeatureAltivec,
FeatureFRES, FeatureFRSQRTE]>;
def : Processor<"7450", G4PlusItineraries, [Directive7400, FeatureAltivec,
FeatureFRES, FeatureFRSQRTE]>;
def : Processor<"g4+", G4PlusItineraries, [Directive7400, FeatureAltivec,
FeatureFRES, FeatureFRSQRTE]>;
Add a SchedMachineModel for the PPC G5 llvm-svn: 178850
2013-04-05 13:49:18 +08:00
def : ProcessorModel<"970", G5Model,
Honor cpu directive, take two. llvm-svn: 32492
2006-12-13 04:57:08 +08:00
[Directive970, FeatureAltivec,
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
FeatureMFOCRF, FeatureFSqrt,
FeatureFRES, FeatureFRSQRTE, FeatureSTFIWX,
Add g3 back to the mix and reorder to irritate them anal folk. Actually, it's to group appropriately and provide cues to maintainers that the lists don't need to be ordered. llvm-svn: 23880
2005-10-22 16:04:24 +08:00
Feature64Bit /*, Feature64BitRegs */]>;
Add a SchedMachineModel for the PPC G5 llvm-svn: 178850
2013-04-05 13:49:18 +08:00
def : ProcessorModel<"g5", G5Model,
Honor cpu directive, take two. llvm-svn: 32492
2006-12-13 04:57:08 +08:00
[Directive970, FeatureAltivec,
Rename the PPC target feature gpul to mfocrf. The PPC target feature gpul (IsGigaProcessor) was only used for one thing: To enable the generation of the MFOCRF instruction. Furthermore, this instruction is available on other PPC cores outside of the G5 line. This feature now corresponds to the HasMFOCRF flag. No functionality change. llvm-svn: 158323
2012-06-12 03:57:01 +08:00
FeatureMFOCRF, FeatureFSqrt, FeatureSTFIWX,
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
FeatureFRES, FeatureFRSQRTE,
Mark PPC MFTB and DST (and friends) as deprecated Use the new instruction deprecation feature to mark mftb (now replaced with mfspr) and dst (along with the other Altivec cache control instructions) as deprecated when targeting cores supporting at least ISA v2.03. llvm-svn: 190605
2013-09-12 22:40:06 +08:00
Feature64Bit /*, Feature64BitRegs */,
DeprecatedMFTB, DeprecatedDST]>;
Add PPC Freescale e500mc and e5500 subtargets. Add subtargets for Freescale e500mc (32-bit) and e5500 (64-bit) to the PowerPC backend. Patch by Tobias von Koch. llvm-svn: 162764
2012-08-29 00:12:39 +08:00
def : ProcessorModel<"e500mc", PPCE500mcModel,
[DirectiveE500mc, FeatureMFOCRF,
Mark PPC MFTB and DST (and friends) as deprecated Use the new instruction deprecation feature to mark mftb (now replaced with mfspr) and dst (along with the other Altivec cache control instructions) as deprecated when targeting cores supporting at least ISA v2.03. llvm-svn: 190605
2013-09-12 22:40:06 +08:00
FeatureSTFIWX, FeatureBookE, FeatureISEL,
DeprecatedMFTB]>;
Add PPC Freescale e500mc and e5500 subtargets. Add subtargets for Freescale e500mc (32-bit) and e5500 (64-bit) to the PowerPC backend. Patch by Tobias von Koch. llvm-svn: 162764
2012-08-29 00:12:39 +08:00
def : ProcessorModel<"e5500", PPCE5500Model,
[DirectiveE5500, FeatureMFOCRF, Feature64Bit,
Mark PPC MFTB and DST (and friends) as deprecated Use the new instruction deprecation feature to mark mftb (now replaced with mfspr) and dst (along with the other Altivec cache control instructions) as deprecated when targeting cores supporting at least ISA v2.03. llvm-svn: 190605
2013-09-12 22:40:06 +08:00
FeatureSTFIWX, FeatureBookE, FeatureISEL,
DeprecatedMFTB]>;
Add a SchedMachineModel for the PPC A2 llvm-svn: 178848
2013-04-05 13:34:08 +08:00
def : ProcessorModel<"a2", PPCA2Model,
Add the PPC64 ldbrx/stdbrx instructions These are 64-bit load/store with byte-swap, and available on the P7 and the A2. Like the similar instructions for 16- and 32-bit words, these are matched in the target DAG-combine phase against load/store-bswap pairs. llvm-svn: 178276
2013-03-29 03:25:55 +08:00
[DirectiveA2, FeatureBookE, FeatureMFOCRF,
Add the PPC fcpsgn instruction Modern PPC cores support a floating-point copysign instruction, and we can use this to lower the FCOPYSIGN node (which is created from calls to the libm copysign function). A couple of extra patterns are necessary because the operand types of FCOPYSIGN need not agree. llvm-svn: 188653
2013-08-19 13:01:02 +08:00
FeatureFCPSGN, FeatureFSqrt, FeatureFRE, FeatureFRES,
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
FeatureFRSQRTE, FeatureFRSQRTES, FeatureRecipPrec,
FeatureSTFIWX, FeatureLFIWAX,
Add more PPC floating-point conversion instructions The P7 and A2 have additional floating-point conversion instructions which allow a direct two-instruction sequence (plus load/store) to convert from all combinations (signed/unsigned i32/i64) <--> (float/double) (on previous cores, only some combinations were directly available). llvm-svn: 178480
2013-04-02 01:52:07 +08:00
FeatureFPRND, FeatureFPCVT, FeatureISEL,
FeaturePOPCNTD, FeatureLDBRX, Feature64Bit
Mark PPC MFTB and DST (and friends) as deprecated Use the new instruction deprecation feature to mark mftb (now replaced with mfspr) and dst (along with the other Altivec cache control instructions) as deprecated when targeting cores supporting at least ISA v2.03. llvm-svn: 190605
2013-09-12 22:40:06 +08:00
/*, Feature64BitRegs */, DeprecatedMFTB]>;
Add a SchedMachineModel for the PPC A2 llvm-svn: 178848
2013-04-05 13:34:08 +08:00
def : ProcessorModel<"a2q", PPCA2Model,
Add the PPC64 ldbrx/stdbrx instructions These are 64-bit load/store with byte-swap, and available on the P7 and the A2. Like the similar instructions for 16- and 32-bit words, these are matched in the target DAG-combine phase against load/store-bswap pairs. llvm-svn: 178276
2013-03-29 03:25:55 +08:00
[DirectiveA2, FeatureBookE, FeatureMFOCRF,
Add the PPC fcpsgn instruction Modern PPC cores support a floating-point copysign instruction, and we can use this to lower the FCOPYSIGN node (which is created from calls to the libm copysign function). A couple of extra patterns are necessary because the operand types of FCOPYSIGN need not agree. llvm-svn: 188653
2013-08-19 13:01:02 +08:00
FeatureFCPSGN, FeatureFSqrt, FeatureFRE, FeatureFRES,
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
FeatureFRSQRTE, FeatureFRSQRTES, FeatureRecipPrec,
FeatureSTFIWX, FeatureLFIWAX,
Add more PPC floating-point conversion instructions The P7 and A2 have additional floating-point conversion instructions which allow a direct two-instruction sequence (plus load/store) to convert from all combinations (signed/unsigned i32/i64) <--> (float/double) (on previous cores, only some combinations were directly available). llvm-svn: 178480
2013-04-02 01:52:07 +08:00
FeatureFPRND, FeatureFPCVT, FeatureISEL,
FeaturePOPCNTD, FeatureLDBRX, Feature64Bit
Mark PPC MFTB and DST (and friends) as deprecated Use the new instruction deprecation feature to mark mftb (now replaced with mfspr) and dst (along with the other Altivec cache control instructions) as deprecated when targeting cores supporting at least ISA v2.03. llvm-svn: 190605
2013-09-12 22:40:06 +08:00
/*, Feature64BitRegs */, FeatureQPX, DeprecatedMFTB]>;
Add a SchedMachineModel for the PPC G5 llvm-svn: 178850
2013-04-05 13:49:18 +08:00
def : ProcessorModel<"pwr3", G5Model,
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
[DirectivePwr3, FeatureAltivec,
FeatureFRES, FeatureFRSQRTE, FeatureMFOCRF,
LLVM enablement for some older PowerPC CPUs llvm-svn: 174230
2013-02-02 06:59:51 +08:00
FeatureSTFIWX, Feature64Bit]>;
Add a SchedMachineModel for the PPC G5 llvm-svn: 178850
2013-04-05 13:49:18 +08:00
def : ProcessorModel<"pwr4", G5Model,
LLVM enablement for some older PowerPC CPUs llvm-svn: 174230
2013-02-02 06:59:51 +08:00
[DirectivePwr4, FeatureAltivec, FeatureMFOCRF,
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
FeatureFSqrt, FeatureFRES, FeatureFRSQRTE,
FeatureSTFIWX, Feature64Bit]>;
Add a SchedMachineModel for the PPC G5 llvm-svn: 178850
2013-04-05 13:49:18 +08:00
def : ProcessorModel<"pwr5", G5Model,
LLVM enablement for some older PowerPC CPUs llvm-svn: 174230
2013-02-02 06:59:51 +08:00
[DirectivePwr5, FeatureAltivec, FeatureMFOCRF,
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
FeatureFSqrt, FeatureFRE, FeatureFRES,
FeatureFRSQRTE, FeatureFRSQRTES,
Mark PPC MFTB and DST (and friends) as deprecated Use the new instruction deprecation feature to mark mftb (now replaced with mfspr) and dst (along with the other Altivec cache control instructions) as deprecated when targeting cores supporting at least ISA v2.03. llvm-svn: 190605
2013-09-12 22:40:06 +08:00
FeatureSTFIWX, Feature64Bit,
DeprecatedMFTB, DeprecatedDST]>;
Add a SchedMachineModel for the PPC G5 llvm-svn: 178850
2013-04-05 13:49:18 +08:00
def : ProcessorModel<"pwr5x", G5Model,
LLVM enablement for some older PowerPC CPUs llvm-svn: 174230
2013-02-02 06:59:51 +08:00
[DirectivePwr5x, FeatureAltivec, FeatureMFOCRF,
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
FeatureFSqrt, FeatureFRE, FeatureFRES,
FeatureFRSQRTE, FeatureFRSQRTES,
Mark PPC MFTB and DST (and friends) as deprecated Use the new instruction deprecation feature to mark mftb (now replaced with mfspr) and dst (along with the other Altivec cache control instructions) as deprecated when targeting cores supporting at least ISA v2.03. llvm-svn: 190605
2013-09-12 22:40:06 +08:00
FeatureSTFIWX, FeatureFPRND, Feature64Bit,
DeprecatedMFTB, DeprecatedDST]>;
Add a SchedMachineModel for the PPC G5 llvm-svn: 178850
2013-04-05 13:49:18 +08:00
def : ProcessorModel<"pwr6", G5Model,
Add POWER6 and POWER7 CPU types to the PPC backend. No functional change; these will be used by upcoming scheduler enhancements. llvm-svn: 158313
2012-06-11 23:43:08 +08:00
[DirectivePwr6, FeatureAltivec,
Add the PPC fcpsgn instruction Modern PPC cores support a floating-point copysign instruction, and we can use this to lower the FCOPYSIGN node (which is created from calls to the libm copysign function). A couple of extra patterns are necessary because the operand types of FCOPYSIGN need not agree. llvm-svn: 188653
2013-08-19 13:01:02 +08:00
FeatureMFOCRF, FeatureFCPSGN, FeatureFSqrt, FeatureFRE,
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
FeatureFRES, FeatureFRSQRTE, FeatureFRSQRTES,
FeatureRecipPrec, FeatureSTFIWX, FeatureLFIWAX,
Mark PPC MFTB and DST (and friends) as deprecated Use the new instruction deprecation feature to mark mftb (now replaced with mfspr) and dst (along with the other Altivec cache control instructions) as deprecated when targeting cores supporting at least ISA v2.03. llvm-svn: 190605
2013-09-12 22:40:06 +08:00
FeatureFPRND, Feature64Bit /*, Feature64BitRegs */,
DeprecatedMFTB, DeprecatedDST]>;
Add a SchedMachineModel for the PPC G5 llvm-svn: 178850
2013-04-05 13:49:18 +08:00
def : ProcessorModel<"pwr6x", G5Model,
LLVM enablement for some older PowerPC CPUs llvm-svn: 174230
2013-02-02 06:59:51 +08:00
[DirectivePwr5x, FeatureAltivec, FeatureMFOCRF,
Add the PPC fcpsgn instruction Modern PPC cores support a floating-point copysign instruction, and we can use this to lower the FCOPYSIGN node (which is created from calls to the libm copysign function). A couple of extra patterns are necessary because the operand types of FCOPYSIGN need not agree. llvm-svn: 188653
2013-08-19 13:01:02 +08:00
FeatureFCPSGN, FeatureFSqrt, FeatureFRE, FeatureFRES,
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
FeatureFRSQRTE, FeatureFRSQRTES, FeatureRecipPrec,
FeatureSTFIWX, FeatureLFIWAX,
Mark PPC MFTB and DST (and friends) as deprecated Use the new instruction deprecation feature to mark mftb (now replaced with mfspr) and dst (along with the other Altivec cache control instructions) as deprecated when targeting cores supporting at least ISA v2.03. llvm-svn: 190605
2013-09-12 22:40:06 +08:00
FeatureFPRND, Feature64Bit,
DeprecatedMFTB, DeprecatedDST]>;
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
def : ProcessorModel<"pwr7", P7Model,
Add POWER6 and POWER7 CPU types to the PPC backend. No functional change; these will be used by upcoming scheduler enhancements. llvm-svn: 158313
2012-06-11 23:43:08 +08:00
[DirectivePwr7, FeatureAltivec,
Add the PPC fcpsgn instruction Modern PPC cores support a floating-point copysign instruction, and we can use this to lower the FCOPYSIGN node (which is created from calls to the libm copysign function). A couple of extra patterns are necessary because the operand types of FCOPYSIGN need not agree. llvm-svn: 188653
2013-08-19 13:01:02 +08:00
FeatureMFOCRF, FeatureFCPSGN, FeatureFSqrt, FeatureFRE,
Use PPC reciprocal estimates with Newton iteration in fast-math mode When unsafe FP math operations are enabled, we can use the fre[s] and frsqrte[s] instructions, which generate reciprocal (sqrt) estimates, together with some Newton iteration, in order to quickly generate floating-point division and sqrt results. All of these instructions are separately optional, and so each has its own feature flag (except for the Altivec instructions, which are covered under the existing Altivec flag). Doing this is not only faster than using the IEEE-compliant fdiv/fsqrt instructions, but allows these computations to be pipelined with other computations in order to hide their overall latency. I've also added a couple of missing fnmsub patterns which turned out to be missing (but are necessary for good code generation of the Newton iterations). Altivec needs a similar fix, but that will probably be more complicated because fneg is expanded for Altivec's v4f32. llvm-svn: 178617
2013-04-03 12:01:11 +08:00
FeatureFRES, FeatureFRSQRTE, FeatureFRSQRTES,
FeatureRecipPrec, FeatureSTFIWX, FeatureLFIWAX,
FeatureFPRND, FeatureFPCVT, FeatureISEL,
FeaturePOPCNTD, FeatureLDBRX,
Mark PPC MFTB and DST (and friends) as deprecated Use the new instruction deprecation feature to mark mftb (now replaced with mfspr) and dst (along with the other Altivec cache control instructions) as deprecated when targeting cores supporting at least ISA v2.03. llvm-svn: 190605
2013-09-12 22:40:06 +08:00
Feature64Bit /*, Feature64BitRegs */,
DeprecatedMFTB, DeprecatedDST]>;
Honor cpu directive, take two. llvm-svn: 32492
2006-12-13 04:57:08 +08:00
def : Processor<"ppc", G3Itineraries, [Directive32]>;
Add a SchedMachineModel for the PPC G5 llvm-svn: 178850
2013-04-05 13:49:18 +08:00
def : ProcessorModel<"ppc64", G5Model,
Honor cpu directive, take two. llvm-svn: 32492
2006-12-13 04:57:08 +08:00
[Directive64, FeatureAltivec,
PPC: Enable FRES and FRSQRTE on the default PPC64 description I discussed this with Bill Schmidt on IRC, and it was decided that this is a safe and reasonable default. llvm-svn: 178659
2013-04-03 22:40:18 +08:00
FeatureMFOCRF, FeatureFSqrt, FeatureFRES,
FeatureFRSQRTE, FeatureSTFIWX,
Add g3 back to the mix and reorder to irritate them anal folk. Actually, it's to group appropriately and provide cues to maintainers that the lists don't need to be ordered. llvm-svn: 23880
2005-10-22 16:04:24 +08:00
Feature64Bit /*, Feature64BitRegs */]>;
[PowerPC] Support powerpc64le as a syntax-checking target. This patch provides basic support for powerpc64le as an LLVM target. However, use of this target will not actually generate little-endian code. Instead, use of the target will cause the correct little-endian built-in defines to be generated, so that code that tests for __LITTLE_ENDIAN__, for example, will be correctly parsed for syntax-only testing. Code generation will otherwise be the same as powerpc64 (big-endian), for now. The patch leaves open the possibility of creating a little-endian PowerPC64 back end, but there is no immediate intent to create such a thing. The LLVM portions of this patch simply add ppc64le coverage everywhere that ppc64 coverage currently exists. There is nothing of any import worth testing until such time as little-endian code generation is implemented. In the corresponding Clang patch, there is a new test case variant to ensure that correct built-in defines for little-endian code are generated. llvm-svn: 187179
2013-07-26 09:35:43 +08:00
def : ProcessorModel<"ppc64le", G5Model,
[Directive64, FeatureAltivec,
FeatureMFOCRF, FeatureFSqrt, FeatureFRES,
FeatureFRSQRTE, FeatureSTFIWX,
Feature64Bit /*, Feature64BitRegs */]>;
Added InstrSchedClass to each of the PowerPC Instructions. Note that when adding new instructions that you should refer to the table at the bottom of PPCSchedule.td. llvm-svn: 23830
2005-10-20 03:51:16 +08:00
Switch PPC return lower to use an autogenerated CC description. llvm-svn: 34940
2007-03-06 08:59:59 +08:00
//===----------------------------------------------------------------------===//
// Calling Conventions
//===----------------------------------------------------------------------===//
include "PPCCallingConv.td"
Several big changes: 1. Use flags on the instructions in the .td file to indicate the PPC970 unit type instead of a table in the .cpp file. Much cleaner. 2. Change the hazard recognizer to build d-groups according to the actual algorithm used, not my flawed understanding of it. 3. Model "must be in the first slot" and "must be the only instr in a group" accurately. llvm-svn: 26719
2006-03-12 17:13:49 +08:00
def PPCInstrInfo : InstrInfo {
let isLittleEndianEncoding = 1;
Add a disassembler to the PowerPC backend The tests for the disassembler were adapted from the encoder tests, and for the most part, the output from the disassembler matches that encoder-test inputs. There are some places where more-informative mnemonics could be produced (notably for the branch instructions), and those cases are noted in the tests with FIXMEs. Future work includes: - Generating more-informative mnemonics when possible (this may also be done in the printer). - Remove the dependence on positional "numbered" operand-to-variable mapping (for both encoding and decoding). - Internally using 64-bit instruction variants in 64-bit mode (if this turns out to matter). llvm-svn: 197693
2013-12-20 00:13:01 +08:00
// FIXME: Unset this when no longer needed!
let decodePositionallyEncodedOperands = 1;
[TableGen] Optionally forbid overlap between named and positional operands There are currently two schemes for mapping instruction operands to instruction-format variables for generating the instruction encoders and decoders for the assembler and disassembler respectively: a) to map by name and b) to map by position. In the long run, we'd like to remove the position-based scheme and use only name-based mapping. Unfortunately, the name-based scheme currently cannot deal with complex operands (those with suboperands), and so we currently must use the position-based scheme for those. On the other hand, the position-based scheme cannot deal with (register) variables that are split into multiple ranges. An upcoming commit to the PowerPC backend (adding VSX support) will require this capability. While we could teach the position-based scheme to handle that, since we'd like to move away from the position-based mapping generally, it seems silly to teach it new tricks now. What makes more sense is to allow for partial transitioning: use the name-based mapping when possible, and only use the position-based scheme when necessary. Now the problem is that mixing the two sensibly was not possible: the position-based mapping would map based on position, but would not skip those variables that were mapped by name. Instead, the two sets of assignments would overlap. However, I cannot currently change the current behavior, because there are some backends that rely on it [I think mistakenly, but I'll send a message to llvmdev about that]. So I've added a new TableGen bit variable: noNamedPositionallyEncodedOperands, that can be used to cause the position-based mapping to skip variables mapped by name. llvm-svn: 203767
2014-03-13 15:57:54 +08:00
let noNamedPositionallyEncodedOperands = 1;
Several big changes: 1. Use flags on the instructions in the .td file to indicate the PPC970 unit type instead of a table in the .cpp file. Much cleaner. 2. Change the hazard recognizer to build d-groups according to the actual algorithm used, not my flawed understanding of it. 3. Model "must be in the first slot" and "must be the only instr in a group" accurately. llvm-svn: 26719
2006-03-12 17:13:49 +08:00
}
[PowerPC] Add assembler parser This adds assembler parser support to the PowerPC back end. The parser will run for any powerpc-*-* and powerpc64-*-* triples, but was tested only on 64-bit Linux. The supported syntax is intended to be compatible with the GNU assembler. The parser does not yet support all PowerPC instructions, but it does support anything that is generated by LLVM itself. There is no support for testing restricted instruction sets yet, i.e. the parser will always accept any instructions it knows, no matter what feature flags are given. Instruction operands will be checked for validity and errors generated. (Error handling in general could still be improved.) The patch adds a number of test cases to verify instruction and operand encodings. The tests currently cover all instructions from the following PowerPC ISA v2.06 Book I facilities: Branch, Fixed-point, Floating-Point, and Vector. Note that a number of these instructions are not yet supported by the back end; they are marked with FIXME. A number of follow-on check-ins will add extra features. When they are all included, LLVM passes all tests (including bootstrap) when using clang -cc1as as the system assembler. llvm-svn: 181050
2013-05-04 03:49:39 +08:00
def PPCAsmParser : AsmParser {
let ShouldEmitMatchRegisterName = 0;
}
[PowerPC] Support basic compare mnemonics This adds support for the basic mnemoics (with the L operand) for the fixed-point compare instructions. These are defined as aliases for the already existing CMPW/CMPD patterns, depending on the value of L. This requires use of InstAlias patterns with immediate literal operands. To make this work, we need two further changes: - define a RegisterPrefix, because otherwise literals 0 and 1 would be parsed as literal register names - provide a PPCAsmParser::validateTargetOperandClass routine to recognize immediate literals (like ARM does) llvm-svn: 185826
2013-07-08 22:49:37 +08:00
def PPCAsmParserVariant : AsmParserVariant {
int Variant = 0;
// We do not use hard coded registers in asm strings. However, some
// InstAlias definitions use immediate literals. Set RegisterPrefix
// so that those are not misinterpreted as registers.
string RegisterPrefix = "%";
}
Eliminate PowerPC.td and PPC32.td, consolidating them into PPC.td llvm-svn: 23738
2005-10-15 07:37:35 +08:00
def PPC : Target {
Several big changes: 1. Use flags on the instructions in the .td file to indicate the PPC970 unit type instead of a table in the .cpp file. Much cleaner. 2. Change the hazard recognizer to build d-groups according to the actual algorithm used, not my flawed understanding of it. 3. Model "must be in the first slot" and "must be the only instr in a group" accurately. llvm-svn: 26719
2006-03-12 17:13:49 +08:00
// Information about the instructions.
let InstructionSet = PPCInstrInfo;
Change the default of AsmWriterClassName and isMCAsmWriter. llvm-svn: 196065
2013-12-02 12:55:42 +08:00
[PowerPC] Add assembler parser This adds assembler parser support to the PowerPC back end. The parser will run for any powerpc-*-* and powerpc64-*-* triples, but was tested only on 64-bit Linux. The supported syntax is intended to be compatible with the GNU assembler. The parser does not yet support all PowerPC instructions, but it does support anything that is generated by LLVM itself. There is no support for testing restricted instruction sets yet, i.e. the parser will always accept any instructions it knows, no matter what feature flags are given. Instruction operands will be checked for validity and errors generated. (Error handling in general could still be improved.) The patch adds a number of test cases to verify instruction and operand encodings. The tests currently cover all instructions from the following PowerPC ISA v2.06 Book I facilities: Branch, Fixed-point, Floating-Point, and Vector. Note that a number of these instructions are not yet supported by the back end; they are marked with FIXME. A number of follow-on check-ins will add extra features. When they are all included, LLVM passes all tests (including bootstrap) when using clang -cc1as as the system assembler. llvm-svn: 181050
2013-05-04 03:49:39 +08:00
let AssemblyParsers = [PPCAsmParser];
[PowerPC] Support basic compare mnemonics This adds support for the basic mnemoics (with the L operand) for the fixed-point compare instructions. These are defined as aliases for the already existing CMPW/CMPD patterns, depending on the value of L. This requires use of InstAlias patterns with immediate literal operands. To make this work, we need two further changes: - define a RegisterPrefix, because otherwise literals 0 and 1 would be parsed as literal register names - provide a PPCAsmParser::validateTargetOperandClass routine to recognize immediate literals (like ARM does) llvm-svn: 185826
2013-07-08 22:49:37 +08:00
let AssemblyParserVariants = [PPCAsmParserVariant];
Eliminate PowerPC.td and PPC32.td, consolidating them into PPC.td llvm-svn: 23738
2005-10-15 07:37:35 +08:00
}