2012-02-18 20:03:15 +08:00
|
|
|
//===-- PPC.td - Describe the PowerPC Target Machine -------*- tablegen -*-===//
|
|
|
|
|
//
|
2005-10-15 07:37:35 +08:00
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
|
//
|
2007-12-30 04:36:04 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
|
// License. See LICENSE.TXT for details.
|
2012-02-18 20:03:15 +08:00
|
|
|
//
|
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.
|
|
|
|
|
//
|
2008-11-24 15:34:46 +08:00
|
|
|
include "llvm/Target/Target.td"
|
2005-10-15 07:37:35 +08:00
|
|
|
|
2005-10-20 03:51:16 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2005-10-22 16:04:24 +08:00
|
|
|
// PowerPC Subtarget features.
|
2005-10-20 03:51:16 +08:00
|
|
|
//
|
2015-03-05 01:09:12 +08:00
|
|
|
|
2006-12-13 04:57:08 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// CPU Directives //
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2011-10-17 12:03:49 +08:00
|
|
|
def Directive440 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_440", "">;
|
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", "">;
|
2012-04-02 03:22:40 +08:00
|
|
|
def DirectiveA2 : SubtargetFeature<"", "DarwinDirective", "PPC::DIR_A2", "">;
|
2012-08-29 00:12:39 +08:00
|
|
|
def DirectiveE500mc : SubtargetFeature<"", "DarwinDirective",
|
|
|
|
|
"PPC::DIR_E500mc", "">;
|
2016-06-23 09:33:38 +08:00
|
|
|
def DirectiveE5500 : SubtargetFeature<"", "DarwinDirective",
|
2012-08-29 00:12:39 +08:00
|
|
|
"PPC::DIR_E5500", "">;
|
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", "">;
|
2016-06-23 09:33:38 +08:00
|
|
|
def DirectivePwr5x
|
|
|
|
|
: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR5X", "">;
|
2012-06-11 23:43:08 +08:00
|
|
|
def DirectivePwr6: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR6", "">;
|
2016-06-23 09:33:38 +08:00
|
|
|
def DirectivePwr6x
|
|
|
|
|
: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR6X", "">;
|
2012-06-11 23:43:08 +08:00
|
|
|
def DirectivePwr7: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR7", "">;
|
2014-06-26 21:36:19 +08:00
|
|
|
def DirectivePwr8: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR8", "">;
|
2016-05-10 02:54:58 +08:00
|
|
|
def DirectivePwr9: SubtargetFeature<"", "DarwinDirective", "PPC::DIR_PWR9", "">;
|
2006-12-13 04:57:08 +08:00
|
|
|
|
2006-06-17 01:34:12 +08:00
|
|
|
def Feature64Bit : SubtargetFeature<"64bit","Has64BitSupport", "true",
|
2005-10-23 13:28:51 +08:00
|
|
|
"Enable 64-bit instructions">;
|
[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
|
|
|
def FeatureHardFloat : SubtargetFeature<"hard-float", "HasHardFloat", "true",
|
|
|
|
|
"Enable floating-point instructions">;
|
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">;
|
2006-01-27 16:09:42 +08:00
|
|
|
def FeatureAltivec : SubtargetFeature<"altivec","HasAltivec", "true",
|
[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
|
|
|
"Enable Altivec instructions",
|
|
|
|
|
[FeatureHardFloat]>;
|
2014-08-07 20:18:21 +08:00
|
|
|
def FeatureSPE : SubtargetFeature<"spe","HasSPE", "true",
|
[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
|
|
|
"Enable SPE instructions",
|
|
|
|
|
[FeatureHardFloat]>;
|
2012-06-12 03:57:01 +08:00
|
|
|
def FeatureMFOCRF : SubtargetFeature<"mfocrf","HasMFOCRF", "true",
|
|
|
|
|
"Enable the MFOCRF instruction">;
|
2006-01-27 16:09:42 +08:00
|
|
|
def FeatureFSqrt : SubtargetFeature<"fsqrt","HasFSQRT", "true",
|
[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
|
|
|
"Enable the fsqrt instruction",
|
|
|
|
|
[FeatureHardFloat]>;
|
2013-08-19 13:01:02 +08:00
|
|
|
def FeatureFCPSGN : SubtargetFeature<"fcpsgn", "HasFCPSGN", "true",
|
[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
|
|
|
"Enable the fcpsgn instruction",
|
|
|
|
|
[FeatureHardFloat]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def FeatureFRE : SubtargetFeature<"fre", "HasFRE", "true",
|
[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
|
|
|
"Enable the fre instruction",
|
|
|
|
|
[FeatureHardFloat]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def FeatureFRES : SubtargetFeature<"fres", "HasFRES", "true",
|
[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
|
|
|
"Enable the fres instruction",
|
|
|
|
|
[FeatureHardFloat]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def FeatureFRSQRTE : SubtargetFeature<"frsqrte", "HasFRSQRTE", "true",
|
[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
|
|
|
"Enable the frsqrte instruction",
|
|
|
|
|
[FeatureHardFloat]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def FeatureFRSQRTES : SubtargetFeature<"frsqrtes", "HasFRSQRTES", "true",
|
[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
|
|
|
"Enable the frsqrtes instruction",
|
|
|
|
|
[FeatureHardFloat]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def FeatureRecipPrec : SubtargetFeature<"recipprec", "HasRecipPrec", "true",
|
|
|
|
|
"Assume higher precision reciprocal estimates">;
|
2006-02-28 15:08:22 +08:00
|
|
|
def FeatureSTFIWX : SubtargetFeature<"stfiwx","HasSTFIWX", "true",
|
[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
|
|
|
"Enable the stfiwx instruction",
|
|
|
|
|
[FeatureHardFloat]>;
|
2013-03-31 18:12:51 +08:00
|
|
|
def FeatureLFIWAX : SubtargetFeature<"lfiwax","HasLFIWAX", "true",
|
[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
|
|
|
"Enable the lfiwax instruction",
|
|
|
|
|
[FeatureHardFloat]>;
|
2013-03-29 16:57:48 +08:00
|
|
|
def FeatureFPRND : SubtargetFeature<"fprnd", "HasFPRND", "true",
|
[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
|
|
|
"Enable the fri[mnpz] instructions",
|
|
|
|
|
[FeatureHardFloat]>;
|
2013-04-02 01:52:07 +08:00
|
|
|
def FeatureFPCVT : SubtargetFeature<"fpcvt", "HasFPCVT", "true",
|
[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
|
|
|
"Enable fc[ft]* (unsigned and single-precision) and lfiwzx instructions",
|
|
|
|
|
[FeatureHardFloat]>;
|
2012-06-23 07:10:08 +08:00
|
|
|
def FeatureISEL : SubtargetFeature<"isel","HasISEL", "true",
|
|
|
|
|
"Enable the isel instruction">;
|
2015-04-10 07:54:37 +08:00
|
|
|
def FeatureBPERMD : SubtargetFeature<"bpermd", "HasBPERMD", "true",
|
|
|
|
|
"Enable the bpermd instruction">;
|
|
|
|
|
def FeatureExtDiv : SubtargetFeature<"extdiv", "HasExtDiv", "true",
|
|
|
|
|
"Enable extended divide instructions">;
|
2013-03-29 03:25:55 +08:00
|
|
|
def FeatureLDBRX : SubtargetFeature<"ldbrx","HasLDBRX", "true",
|
|
|
|
|
"Enable the ldbrx instruction">;
|
2015-01-03 09:16:37 +08:00
|
|
|
def FeatureCMPB : SubtargetFeature<"cmpb", "HasCMPB", "true",
|
|
|
|
|
"Enable the cmpb instruction">;
|
2015-01-15 04:17:10 +08:00
|
|
|
def FeatureICBT : SubtargetFeature<"icbt","HasICBT", "true",
|
|
|
|
|
"Enable icbt instruction">;
|
2011-10-17 12:03:49 +08:00
|
|
|
def FeatureBookE : SubtargetFeature<"booke", "IsBookE", "true",
|
2015-01-15 04:17:10 +08:00
|
|
|
"Enable Book E instructions",
|
|
|
|
|
[FeatureICBT]>;
|
2014-10-03 06:34:22 +08:00
|
|
|
def FeatureMSYNC : SubtargetFeature<"msync", "HasOnlyMSYNC", "true",
|
|
|
|
|
"Has only the msync instruction instead of sync",
|
|
|
|
|
[FeatureBookE]>;
|
2014-08-07 20:31:28 +08:00
|
|
|
def FeatureE500 : SubtargetFeature<"e500", "IsE500", "true",
|
2014-08-04 23:47:38 +08:00
|
|
|
"Enable E500/E500mc instructions">;
|
|
|
|
|
def FeaturePPC4xx : SubtargetFeature<"ppc4xx", "IsPPC4xx", "true",
|
|
|
|
|
"Enable PPC 4xx instructions">;
|
2014-08-05 01:07:41 +08:00
|
|
|
def FeaturePPC6xx : SubtargetFeature<"ppc6xx", "IsPPC6xx", "true",
|
|
|
|
|
"Enable PPC 6xx instructions">;
|
2013-01-31 05:17:42 +08:00
|
|
|
def FeatureQPX : SubtargetFeature<"qpx","HasQPX", "true",
|
[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
|
|
|
"Enable QPX instructions",
|
|
|
|
|
[FeatureHardFloat]>;
|
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]>;
|
2015-02-04 05:58:23 +08:00
|
|
|
def FeatureP8Altivec : SubtargetFeature<"power8-altivec", "HasP8Altivec", "true",
|
|
|
|
|
"Enable POWER8 Altivec instructions",
|
|
|
|
|
[FeatureAltivec]>;
|
2015-03-05 04:44:33 +08:00
|
|
|
def FeatureP8Crypto : SubtargetFeature<"crypto", "HasP8Crypto", "true",
|
2015-03-11 04:51:07 +08:00
|
|
|
"Enable POWER8 Crypto instructions",
|
|
|
|
|
[FeatureP8Altivec]>;
|
2014-12-09 09:03:27 +08:00
|
|
|
def FeatureP8Vector : SubtargetFeature<"power8-vector", "HasP8Vector", "true",
|
|
|
|
|
"Enable POWER8 vector instructions",
|
2015-02-04 05:58:23 +08:00
|
|
|
[FeatureVSX, FeatureP8Altivec]>;
|
2015-04-11 18:40:42 +08:00
|
|
|
def FeatureDirectMove :
|
|
|
|
|
SubtargetFeature<"direct-move", "HasDirectMove", "true",
|
|
|
|
|
"Enable Power8 direct move instructions",
|
|
|
|
|
[FeatureVSX]>;
|
2015-03-11 04:51:07 +08:00
|
|
|
def FeaturePartwordAtomic : SubtargetFeature<"partword-atomics",
|
|
|
|
|
"HasPartwordAtomics", "true",
|
|
|
|
|
"Enable l[bh]arx and st[bh]cx.">;
|
[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
|
|
|
def FeatureInvariantFunctionDescriptors :
|
|
|
|
|
SubtargetFeature<"invariant-function-descriptors",
|
|
|
|
|
"HasInvariantFunctionDescriptors", "true",
|
|
|
|
|
"Assume function descriptors are invariant">;
|
2016-08-30 08:59:23 +08:00
|
|
|
def FeatureLongCall : SubtargetFeature<"longcall", "UseLongCalls", "true",
|
|
|
|
|
"Always use indirect calls">;
|
2015-03-26 03:36:23 +08:00
|
|
|
def FeatureHTM : SubtargetFeature<"htm", "HasHTM", "true",
|
|
|
|
|
"Enable Hardware Transactional Memory instructions">;
|
2015-06-17 00:01:15 +08:00
|
|
|
def FeatureMFTB : SubtargetFeature<"", "FeatureMFTB", "true",
|
|
|
|
|
"Implement mftb using the mfspr instruction">;
|
2015-11-21 06:38:20 +08:00
|
|
|
def FeatureFusion : SubtargetFeature<"fusion", "HasFusion", "true",
|
|
|
|
|
"Target supports add/load integer fusion.">;
|
2015-12-15 20:19:34 +08:00
|
|
|
def FeatureFloat128 :
|
|
|
|
|
SubtargetFeature<"float128", "HasFloat128", "true",
|
|
|
|
|
"Enable the __float128 data type for IEEE-754R Binary128.",
|
|
|
|
|
[FeatureVSX]>;
|
2016-03-29 09:36:01 +08:00
|
|
|
def FeaturePOPCNTD : SubtargetFeature<"popcntd","HasPOPCNTD",
|
|
|
|
|
"POPCNTD_Fast",
|
|
|
|
|
"Enable the popcnt[dw] instructions">;
|
2016-03-29 01:52:08 +08:00
|
|
|
// Note that for the a2/a2q processor models we should not use popcnt[dw] by
|
|
|
|
|
// default. These processors do support the instructions, but they're
|
|
|
|
|
// microcoded, and the software emulation is about twice as fast.
|
2016-03-29 09:36:01 +08:00
|
|
|
def FeatureSlowPOPCNTD : SubtargetFeature<"slow-popcntd","HasPOPCNTD",
|
|
|
|
|
"POPCNTD_Slow",
|
|
|
|
|
"Has slow popcnt[dw] instructions">;
|
|
|
|
|
|
|
|
|
|
def DeprecatedDST : SubtargetFeature<"", "DeprecatedDST", "true",
|
|
|
|
|
"Treat vector data stream cache control instructions as deprecated">;
|
2016-03-29 01:52:08 +08:00
|
|
|
|
2016-03-31 23:26:37 +08:00
|
|
|
def FeatureISA3_0 : SubtargetFeature<"isa-v30-instructions", "IsISA3_0",
|
|
|
|
|
"true",
|
|
|
|
|
"Enable instructions added in ISA 3.0.">;
|
2016-04-14 02:51:18 +08:00
|
|
|
def FeatureP9Altivec : SubtargetFeature<"power9-altivec", "HasP9Altivec", "true",
|
|
|
|
|
"Enable POWER9 Altivec instructions",
|
|
|
|
|
[FeatureISA3_0, FeatureP8Altivec]>;
|
|
|
|
|
def FeatureP9Vector : SubtargetFeature<"power9-vector", "HasP9Vector", "true",
|
|
|
|
|
"Enable POWER9 vector instructions",
|
|
|
|
|
[FeatureISA3_0, FeatureP8Vector,
|
|
|
|
|
FeatureP9Altivec]>;
|
2016-03-31 23:26:37 +08:00
|
|
|
|
2016-06-23 09:33:38 +08:00
|
|
|
// Since new processors generally contain a superset of features of those that
|
|
|
|
|
// came before them, the idea is to make implementations of new processors
|
|
|
|
|
// less error prone and easier to read.
|
|
|
|
|
// Namely:
|
|
|
|
|
// list<SubtargetFeature> Power8FeatureList = ...
|
|
|
|
|
// list<SubtargetFeature> FutureProcessorSpecificFeatureList =
|
|
|
|
|
// [ features that Power8 does not support ]
|
|
|
|
|
// list<SubtargetFeature> FutureProcessorFeatureList =
|
|
|
|
|
// !listconcat(Power8FeatureList, FutureProcessorSpecificFeatureList)
|
2015-04-10 07:54:37 +08:00
|
|
|
|
2016-06-23 09:33:38 +08:00
|
|
|
// Makes it explicit and obvious what is new in FutureProcesor vs. Power8 as
|
|
|
|
|
// well as providing a single point of definition if the feature set will be
|
|
|
|
|
// used elsewhere.
|
2015-04-10 07:54:37 +08:00
|
|
|
def ProcessorFeatures {
|
|
|
|
|
list<SubtargetFeature> Power7FeatureList =
|
|
|
|
|
[DirectivePwr7, FeatureAltivec, FeatureVSX,
|
|
|
|
|
FeatureMFOCRF, FeatureFCPSGN, FeatureFSqrt, FeatureFRE,
|
|
|
|
|
FeatureFRES, FeatureFRSQRTE, FeatureFRSQRTES,
|
|
|
|
|
FeatureRecipPrec, FeatureSTFIWX, FeatureLFIWAX,
|
|
|
|
|
FeatureFPRND, FeatureFPCVT, FeatureISEL,
|
|
|
|
|
FeaturePOPCNTD, FeatureCMPB, FeatureLDBRX,
|
2015-04-11 21:40:36 +08:00
|
|
|
Feature64Bit /*, Feature64BitRegs */,
|
2015-04-10 07:54:37 +08:00
|
|
|
FeatureBPERMD, FeatureExtDiv,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureMFTB, DeprecatedDST];
|
2015-04-10 07:54:37 +08:00
|
|
|
list<SubtargetFeature> Power8SpecificFeatures =
|
|
|
|
|
[DirectivePwr8, FeatureP8Altivec, FeatureP8Vector, FeatureP8Crypto,
|
2015-11-21 06:38:20 +08:00
|
|
|
FeatureHTM, FeatureDirectMove, FeatureICBT, FeaturePartwordAtomic,
|
|
|
|
|
FeatureFusion];
|
2015-04-10 07:54:37 +08:00
|
|
|
list<SubtargetFeature> Power8FeatureList =
|
|
|
|
|
!listconcat(Power7FeatureList, Power8SpecificFeatures);
|
2016-04-14 02:51:18 +08:00
|
|
|
list<SubtargetFeature> Power9SpecificFeatures =
|
2016-09-14 22:09:39 +08:00
|
|
|
[DirectivePwr9, FeatureP9Altivec, FeatureP9Vector, FeatureISA3_0];
|
2016-05-10 02:54:58 +08:00
|
|
|
list<SubtargetFeature> Power9FeatureList =
|
|
|
|
|
!listconcat(Power8FeatureList, Power9SpecificFeatures);
|
2015-04-10 07:54:37 +08:00
|
|
|
}
|
|
|
|
|
|
2013-02-02 07:10:09 +08:00
|
|
|
// Note: Future features to add when support is extended to more
|
|
|
|
|
// recent ISA levels:
|
|
|
|
|
//
|
|
|
|
|
// DFP p6, p6x, p7 decimal floating-point instructions
|
|
|
|
|
// POPCNTB p5 through p7 popcntb and related instructions
|
|
|
|
|
|
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;
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
|
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"]];
|
|
|
|
|
}
|
|
|
|
|
|
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"]];
|
|
|
|
|
}
|
|
|
|
|
|
2005-10-20 03:51:16 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2005-10-24 06:08:13 +08:00
|
|
|
// Register File Description
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
include "PPCRegisterInfo.td"
|
|
|
|
|
include "PPCSchedule.td"
|
|
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// PowerPC processors supported.
|
2005-10-20 03:51:16 +08:00
|
|
|
//
|
|
|
|
|
|
[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
|
|
|
def : Processor<"generic", G3Itineraries, [Directive32, FeatureHardFloat,
|
|
|
|
|
FeatureMFTB]>;
|
2013-11-29 14:32:17 +08:00
|
|
|
def : ProcessorModel<"440", PPC440Model, [Directive440, FeatureISEL,
|
|
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
2015-01-15 04:17:10 +08:00
|
|
|
FeatureICBT, FeatureBookE,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureMSYNC, FeatureMFTB]>;
|
2013-11-29 14:32:17 +08:00
|
|
|
def : ProcessorModel<"450", PPC440Model, [Directive440, FeatureISEL,
|
|
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
2015-01-15 04:17:10 +08:00
|
|
|
FeatureICBT, FeatureBookE,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureMSYNC, FeatureMFTB]>;
|
[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
|
|
|
def : Processor<"601", G3Itineraries, [Directive601, FeatureHardFloat]>;
|
|
|
|
|
def : Processor<"602", G3Itineraries, [Directive602, FeatureHardFloat,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureMFTB]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Processor<"603", G3Itineraries, [Directive603,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Processor<"603e", G3Itineraries, [Directive603,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Processor<"603ev", G3Itineraries, [Directive603,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Processor<"604", G3Itineraries, [Directive604,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Processor<"604e", G3Itineraries, [Directive604,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Processor<"620", G3Itineraries, [Directive620,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Processor<"750", G4Itineraries, [Directive750,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Processor<"g3", G3Itineraries, [Directive750,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Processor<"7400", G4Itineraries, [Directive7400, FeatureAltivec,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Processor<"g4", G4Itineraries, [Directive7400, FeatureAltivec,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Processor<"7450", G4PlusItineraries, [Directive7400, FeatureAltivec,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-03 12:01:11 +08:00
|
|
|
def : Processor<"g4+", G4PlusItineraries, [Directive7400, FeatureAltivec,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
|
|
|
|
FeatureMFTB]>;
|
2015-01-26 02:05:42 +08:00
|
|
|
|
2013-04-05 13:49:18 +08:00
|
|
|
def : ProcessorModel<"970", G5Model,
|
2006-12-13 04:57:08 +08:00
|
|
|
[Directive970, FeatureAltivec,
|
2013-04-03 12:01:11 +08:00
|
|
|
FeatureMFOCRF, FeatureFSqrt,
|
|
|
|
|
FeatureFRES, FeatureFRSQRTE, FeatureSTFIWX,
|
2015-06-17 00:01:15 +08:00
|
|
|
Feature64Bit /*, Feature64BitRegs */,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-05 13:49:18 +08:00
|
|
|
def : ProcessorModel<"g5", G5Model,
|
2006-12-13 04:57:08 +08:00
|
|
|
[Directive970, FeatureAltivec,
|
2012-06-12 03:57:01 +08:00
|
|
|
FeatureMFOCRF, FeatureFSqrt, FeatureSTFIWX,
|
2013-04-03 12:01:11 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE,
|
2013-09-12 22:40:06 +08:00
|
|
|
Feature64Bit /*, Feature64BitRegs */,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureMFTB, DeprecatedDST]>;
|
2012-08-29 00:12:39 +08:00
|
|
|
def : ProcessorModel<"e500mc", PPCE500mcModel,
|
2015-11-25 18:14:31 +08:00
|
|
|
[DirectiveE500mc,
|
2015-01-15 04:17:10 +08:00
|
|
|
FeatureSTFIWX, FeatureICBT, FeatureBookE,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureISEL, FeatureMFTB]>;
|
2012-08-29 00:12:39 +08:00
|
|
|
def : ProcessorModel<"e5500", PPCE5500Model,
|
|
|
|
|
[DirectiveE5500, FeatureMFOCRF, Feature64Bit,
|
2015-01-15 04:17:10 +08:00
|
|
|
FeatureSTFIWX, FeatureICBT, FeatureBookE,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureISEL, FeatureMFTB]>;
|
2013-04-05 13:34:08 +08:00
|
|
|
def : ProcessorModel<"a2", PPCA2Model,
|
2015-01-15 04:17:10 +08:00
|
|
|
[DirectiveA2, FeatureICBT, FeatureBookE, FeatureMFOCRF,
|
2013-08-19 13:01:02 +08:00
|
|
|
FeatureFCPSGN, FeatureFSqrt, FeatureFRE, FeatureFRES,
|
2013-04-03 12:01:11 +08:00
|
|
|
FeatureFRSQRTE, FeatureFRSQRTES, FeatureRecipPrec,
|
|
|
|
|
FeatureSTFIWX, FeatureLFIWAX,
|
2013-04-02 01:52:07 +08:00
|
|
|
FeatureFPRND, FeatureFPCVT, FeatureISEL,
|
2016-03-29 09:36:01 +08:00
|
|
|
FeatureSlowPOPCNTD, FeatureCMPB, FeatureLDBRX,
|
2016-03-29 01:52:08 +08:00
|
|
|
Feature64Bit /*, Feature64BitRegs */, FeatureMFTB]>;
|
2013-04-05 13:34:08 +08:00
|
|
|
def : ProcessorModel<"a2q", PPCA2Model,
|
2015-01-15 04:17:10 +08:00
|
|
|
[DirectiveA2, FeatureICBT, FeatureBookE, FeatureMFOCRF,
|
2013-08-19 13:01:02 +08:00
|
|
|
FeatureFCPSGN, FeatureFSqrt, FeatureFRE, FeatureFRES,
|
2013-04-03 12:01:11 +08:00
|
|
|
FeatureFRSQRTE, FeatureFRSQRTES, FeatureRecipPrec,
|
|
|
|
|
FeatureSTFIWX, FeatureLFIWAX,
|
2013-04-02 01:52:07 +08:00
|
|
|
FeatureFPRND, FeatureFPCVT, FeatureISEL,
|
2016-03-29 09:36:01 +08:00
|
|
|
FeatureSlowPOPCNTD, FeatureCMPB, FeatureLDBRX,
|
2016-03-29 01:52:08 +08:00
|
|
|
Feature64Bit /*, Feature64BitRegs */, FeatureQPX,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-05 13:49:18 +08:00
|
|
|
def : ProcessorModel<"pwr3", G5Model,
|
2013-04-03 12:01:11 +08:00
|
|
|
[DirectivePwr3, FeatureAltivec,
|
|
|
|
|
FeatureFRES, FeatureFRSQRTE, FeatureMFOCRF,
|
2013-02-02 06:59:51 +08:00
|
|
|
FeatureSTFIWX, Feature64Bit]>;
|
2013-04-05 13:49:18 +08:00
|
|
|
def : ProcessorModel<"pwr4", G5Model,
|
2013-02-02 06:59:51 +08:00
|
|
|
[DirectivePwr4, FeatureAltivec, FeatureMFOCRF,
|
2013-04-03 12:01:11 +08:00
|
|
|
FeatureFSqrt, FeatureFRES, FeatureFRSQRTE,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureSTFIWX, Feature64Bit, FeatureMFTB]>;
|
2013-04-05 13:49:18 +08:00
|
|
|
def : ProcessorModel<"pwr5", G5Model,
|
2013-02-02 06:59:51 +08:00
|
|
|
[DirectivePwr5, FeatureAltivec, FeatureMFOCRF,
|
2013-04-03 12:01:11 +08:00
|
|
|
FeatureFSqrt, FeatureFRE, FeatureFRES,
|
|
|
|
|
FeatureFRSQRTE, FeatureFRSQRTES,
|
2013-09-12 22:40:06 +08:00
|
|
|
FeatureSTFIWX, Feature64Bit,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureMFTB, DeprecatedDST]>;
|
2013-04-05 13:49:18 +08:00
|
|
|
def : ProcessorModel<"pwr5x", G5Model,
|
2013-02-02 06:59:51 +08:00
|
|
|
[DirectivePwr5x, FeatureAltivec, FeatureMFOCRF,
|
2013-04-03 12:01:11 +08:00
|
|
|
FeatureFSqrt, FeatureFRE, FeatureFRES,
|
|
|
|
|
FeatureFRSQRTE, FeatureFRSQRTES,
|
2013-09-12 22:40:06 +08:00
|
|
|
FeatureSTFIWX, FeatureFPRND, Feature64Bit,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureMFTB, DeprecatedDST]>;
|
2013-04-05 13:49:18 +08:00
|
|
|
def : ProcessorModel<"pwr6", G5Model,
|
2012-06-11 23:43:08 +08:00
|
|
|
[DirectivePwr6, FeatureAltivec,
|
2013-08-19 13:01:02 +08:00
|
|
|
FeatureMFOCRF, FeatureFCPSGN, FeatureFSqrt, FeatureFRE,
|
2013-04-03 12:01:11 +08:00
|
|
|
FeatureFRES, FeatureFRSQRTE, FeatureFRSQRTES,
|
2015-01-03 09:16:37 +08:00
|
|
|
FeatureRecipPrec, FeatureSTFIWX, FeatureLFIWAX, FeatureCMPB,
|
2013-09-12 22:40:06 +08:00
|
|
|
FeatureFPRND, Feature64Bit /*, Feature64BitRegs */,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureMFTB, DeprecatedDST]>;
|
2013-04-05 13:49:18 +08:00
|
|
|
def : ProcessorModel<"pwr6x", G5Model,
|
2013-02-02 06:59:51 +08:00
|
|
|
[DirectivePwr5x, FeatureAltivec, FeatureMFOCRF,
|
2013-08-19 13:01:02 +08:00
|
|
|
FeatureFCPSGN, FeatureFSqrt, FeatureFRE, FeatureFRES,
|
2013-04-03 12:01:11 +08:00
|
|
|
FeatureFRSQRTE, FeatureFRSQRTES, FeatureRecipPrec,
|
2015-01-03 09:16:37 +08:00
|
|
|
FeatureSTFIWX, FeatureLFIWAX, FeatureCMPB,
|
2013-09-12 22:40:06 +08:00
|
|
|
FeatureFPRND, Feature64Bit,
|
2015-06-17 00:01:15 +08:00
|
|
|
FeatureMFTB, DeprecatedDST]>;
|
2015-04-10 07:54:37 +08:00
|
|
|
def : ProcessorModel<"pwr7", P7Model, ProcessorFeatures.Power7FeatureList>;
|
2015-01-26 02:05:42 +08:00
|
|
|
def : ProcessorModel<"pwr8", P8Model, ProcessorFeatures.Power8FeatureList>;
|
2016-12-19 21:35:45 +08:00
|
|
|
def : ProcessorModel<"pwr9", P9Model, ProcessorFeatures.Power9FeatureList>;
|
[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
|
|
|
def : Processor<"ppc", G3Itineraries, [Directive32, FeatureHardFloat,
|
|
|
|
|
FeatureMFTB]>;
|
|
|
|
|
def : Processor<"ppc32", G3Itineraries, [Directive32, FeatureHardFloat,
|
|
|
|
|
FeatureMFTB]>;
|
2013-04-05 13:49:18 +08:00
|
|
|
def : ProcessorModel<"ppc64", G5Model,
|
2006-12-13 04:57:08 +08:00
|
|
|
[Directive64, FeatureAltivec,
|
2013-04-03 22:40:18 +08:00
|
|
|
FeatureMFOCRF, FeatureFSqrt, FeatureFRES,
|
|
|
|
|
FeatureFRSQRTE, FeatureSTFIWX,
|
2015-06-17 00:01:15 +08:00
|
|
|
Feature64Bit /*, Feature64BitRegs */,
|
|
|
|
|
FeatureMFTB]>;
|
2015-01-26 02:05:42 +08:00
|
|
|
def : ProcessorModel<"ppc64le", P8Model, ProcessorFeatures.Power8FeatureList>;
|
2005-10-20 03:51:16 +08:00
|
|
|
|
2007-03-06 08:59:59 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// Calling Conventions
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
include "PPCCallingConv.td"
|
|
|
|
|
|
2006-03-12 17:13:49 +08:00
|
|
|
def PPCInstrInfo : InstrInfo {
|
|
|
|
|
let isLittleEndianEncoding = 1;
|
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;
|
2006-03-12 17:13:49 +08:00
|
|
|
}
|
|
|
|
|
|
2013-05-04 03:49:39 +08:00
|
|
|
def PPCAsmParser : AsmParser {
|
|
|
|
|
let ShouldEmitMatchRegisterName = 0;
|
|
|
|
|
}
|
|
|
|
|
|
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 = "%";
|
2015-11-09 08:31:07 +08:00
|
|
|
string BreakCharacters = ".";
|
2013-07-08 22:49:37 +08:00
|
|
|
}
|
|
|
|
|
|
2005-10-15 07:37:35 +08:00
|
|
|
def PPC : Target {
|
2006-03-12 17:13:49 +08:00
|
|
|
// Information about the instructions.
|
|
|
|
|
let InstructionSet = PPCInstrInfo;
|
2013-12-02 12:55:42 +08:00
|
|
|
|
2013-05-04 03:49:39 +08:00
|
|
|
let AssemblyParsers = [PPCAsmParser];
|
2013-07-08 22:49:37 +08:00
|
|
|
let AssemblyParserVariants = [PPCAsmParserVariant];
|
2005-10-15 07:37:35 +08:00
|
|
|
}
|