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/ARM/ARM.td

441 lines
22 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
//===-- ARM.td - Describe the ARM Target Machine -----------*- tablegen -*-===//
added a skeleton of the ARM backend llvm-svn: 28301
2006-05-15 06:18:28 +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
added a skeleton of the ARM backend llvm-svn: 28301
2006-05-15 06:18:28 +08:00
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
//
//===----------------------------------------------------------------------===//
//===----------------------------------------------------------------------===//
// 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"
added a skeleton of the ARM backend llvm-svn: 28301
2006-05-15 06:18:28 +08:00
Sink feature IsThumb into MC layer. llvm-svn: 134608
2011-07-07 16:26:46 +08:00
//===----------------------------------------------------------------------===//
// ARM Subtarget state.
//
Rename attribute 'thumb' to a more descriptive 'thumb-mode'. llvm-svn: 134626
2011-07-08 03:05:12 +08:00
def ModeThumb : SubtargetFeature<"thumb-mode", "InThumbMode", "true",
Sink feature IsThumb into MC layer. llvm-svn: 134608
2011-07-07 16:26:46 +08:00
"Thumb mode">;
Nuke it from orbit. It's the only way to be sure. (Kill the dead non-MC asm printer for the ARM target.) llvm-svn: 115127
2010-09-30 09:57:53 +08:00
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
//===----------------------------------------------------------------------===//
// ARM Subtarget features.
//
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def FeatureVFP2 : SubtargetFeature<"vfp2", "HasVFPv2", "true",
Add placeholder for thumb2 stuff llvm-svn: 72593
2009-05-30 07:41:08 +08:00
"Enable VFP2 instructions">;
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def FeatureVFP3 : SubtargetFeature<"vfp3", "HasVFPv3", "true",
"Enable VFP3 instructions",
[FeatureVFP2]>;
def FeatureNEON : SubtargetFeature<"neon", "HasNEON", "true",
"Enable NEON instructions",
[FeatureVFP3]>;
Factor ARM triple parsing out of ARMSubtarget. Another step towards making ARM subtarget info available to MC. llvm-svn: 134569
2011-07-07 08:08:19 +08:00
def FeatureThumb2 : SubtargetFeature<"thumb2", "HasThumb2", "true",
Add placeholder for thumb2 stuff llvm-svn: 72593
2009-05-30 07:41:08 +08:00
"Enable Thumb2 instructions">;
Report error if codegen tries to instantiate a ARM target when the cpu does support it. e.g. cortex-m* processors. llvm-svn: 110798
2010-08-11 15:17:46 +08:00
def FeatureNoARM : SubtargetFeature<"noarm", "NoARM", "true",
ARM: diagnose ARM/Thumb assembly switches on CPUs only supporting one. Some ARM CPUs only support ARM mode (ancient v4 ones, for example) and some only support Thumb mode (M-class ones currently). This makes sure such CPUs default to the correct mode and makes the AsmParser diagnose an attempt to switch modes incorrectly. rdar://14024354 llvm-svn: 183710
2013-06-11 07:20:58 +08:00
"Does not support ARM mode execution",
[ModeThumb]>;
Add substarget feature for FP16 llvm-svn: 98503
2010-03-15 02:42:38 +08:00
def FeatureFP16 : SubtargetFeature<"fp16", "HasFP16", "true",
"Enable half-precision floating point">;
Add LLVM support for Swift. llvm-svn: 164899
2012-09-30 05:43:49 +08:00
def FeatureVFP4 : SubtargetFeature<"vfp4", "HasVFPv4", "true",
"Enable VFP4 instructions",
[FeatureVFP3, FeatureFP16]>;
[ARMv8] Change hasV8Fp to hasFPARMv8, and other command line options to be more consistent. llvm-svn: 190692
2013-09-13 21:46:57 +08:00
def FeatureFPARMv8 : SubtargetFeature<"fp-armv8", "HasFPARMv8",
Add a Subtarget feature 'v8fp' to the ARM backend. llvm-svn: 185073
2013-06-27 19:49:26 +08:00
"true", "Enable ARMv8 FP",
[FeatureVFP4]>;
PR8359: The ARM backend may end up allocating registers D16 to D31 when "-mattr=+vfp3" is specified. However, this will not work for hardware that only supports 16 registers. Add a new flag to support -"mattr=+vfp3,+d16". Patch by Jan Voung! llvm-svn: 116310
2010-10-13 00:22:47 +08:00
def FeatureD16 : SubtargetFeature<"d16", "HasD16", "true",
"Restrict VFP3 to 16 double registers">;
Cleanup of ARMv7M support. Move hardware divide and Thumb2 extract/pack instructions to subtarget features and update tests to reflect. PR5717. llvm-svn: 103136
2010-05-06 07:44:43 +08:00
def FeatureHWDiv : SubtargetFeature<"hwdiv", "HasHardwareDivide", "true",
"Enable divide instructions">;
Add LLVM support for Swift. llvm-svn: 164899
2012-09-30 05:43:49 +08:00
def FeatureHWDivARM : SubtargetFeature<"hwdiv-arm",
"HasHardwareDivideInARM", "true",
"Enable divide instructions in ARM mode">;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) llvm-svn: 110795
2010-08-11 14:51:54 +08:00
def FeatureT2XtPk : SubtargetFeature<"t2xtpk", "HasT2ExtractPack", "true",
Cleanup of ARMv7M support. Move hardware divide and Thumb2 extract/pack instructions to subtarget features and update tests to reflect. PR5717. llvm-svn: 103136
2010-05-06 07:44:43 +08:00
"Enable Thumb2 extract and pack instructions">;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) llvm-svn: 110795
2010-08-11 14:51:54 +08:00
def FeatureDB : SubtargetFeature<"db", "HasDataBarrier", "true",
"Has data barrier (dmb / dsb) instructions">;
Add an ARM "feature". Cortex-a8 fp comparison is very slow (> 20 cycles). llvm-svn: 108256
2010-07-14 03:21:50 +08:00
def FeatureSlowFPBrcc : SubtargetFeature<"slow-fp-brcc", "SlowFPBrcc", "true",
"FP compare + branch is slow">;
cortex m4 has floating point support, but only single precision. llvm-svn: 110810
2010-08-11 23:44:15 +08:00
def FeatureVFPOnlySP : SubtargetFeature<"fp-only-sp", "FPOnlySP", "true",
"Floating point unit supports single precision only">;
ARM: Add Performance Monitor Extensions feature Performance monitors, including a basic cycle counter, are an official extension in the ARMv7 specification. This adds support for enabling and disabling them, orthogonally from CPU selection. rdar://problem/13939186 llvm-svn: 182602
2013-05-24 03:11:14 +08:00
def FeaturePerfMon : SubtargetFeature<"perfmon", "HasPerfMon", "true",
"Enable support for Performance Monitor extensions">;
ARM: Make "SMC" instructions conditional on new TrustZone architecture feature. These instructions aren't universally available, but depend on a specific extension to the normal ARM architecture (rather than, say, v6/v7/...) so a new feature is appropriate. This also enables the feature by default on A-class cores which usually have these extensions, to avoid breaking existing code and act as a sensible default. llvm-svn: 179171
2013-04-10 20:08:35 +08:00
def FeatureTrustZone : SubtargetFeature<"trustzone", "HasTrustZone", "true",
"Enable support for TrustZone security extensions">;
[ARMv8] Add support for the v8 cryptography extensions. llvm-svn: 190996
2013-09-19 19:59:01 +08:00
def FeatureCrypto : SubtargetFeature<"crypto", "HasCrypto", "true",
"Enable support for Cryptography extensions",
[FeatureNEON]>;
ARM: Add subtarget feature for CRC Adds a subtarget feature for the CRC instructions (optional in v8-A) to the ARM (32-bit) backend. Differential Revision: http://llvm-reviews.chandlerc.com/D2036 llvm-svn: 193599
2013-10-29 17:47:35 +08:00
def FeatureCRC : SubtargetFeature<"crc", "HasCRC", "true",
"Enable support for CRC instructions">;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
ARM: add cyclone CPU with ZeroCycleZeroing feature. The Cyclone CPU is similar to swift for most LLVM purposes, but does have two preferred instructions for zeroing a VFP register. This teaches LLVM about them. llvm-svn: 205309
2014-04-01 21:22:02 +08:00
// Cyclone has preferred instructions for zeroing VFP registers, which can
// execute in 0 cycles.
def FeatureZCZeroing : SubtargetFeature<"zcz", "HasZeroCycleZeroing", "true",
"Has zero-cycle zeroing instructions">;
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
// Some processors have FP multiply-accumulate instructions that don't
// play nicely with other VFP / NEON instructions, and it's generally better
switch the use-vml[as] instructions flag to a subtarget 'feature' llvm-svn: 99565
2010-03-26 07:11:16 +08:00
// to just not use them.
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
def FeatureHasSlowFPVMLx : SubtargetFeature<"slowfpvmlx", "SlowFPVMLx", "true",
"Disable VFP / NEON MAC instructions">;
Distribute (A + B) * C to (A * C) + (B * C) to make use of NEON multiplier accumulator forwarding: vadd d3, d0, d1 vmul d3, d3, d2 => vmul d3, d0, d2 vmla d3, d1, d2 llvm-svn: 128665
2011-04-01 03:38:48 +08:00
// Cortex-A8 / A9 Advanced SIMD has multiplier accumulator forwarding.
def FeatureVMLxForwarding : SubtargetFeature<"vmlx-forwarding",
"HasVMLxForwarding", "true",
"Has multiplier accumulator forwarding">;
switch the flag for using NEON for SP floating point to a subtarget 'feature'. Re-commit. This time complete with testsuite updates. llvm-svn: 99570
2010-03-26 07:47:34 +08:00
// Some processors benefit from using NEON instructions for scalar
// single-precision FP operations.
80 column cleanup. llvm-svn: 111266
2010-08-18 02:39:16 +08:00
def FeatureNEONForFP : SubtargetFeature<"neonfp", "UseNEONForSinglePrecisionFP",
"true",
"Use NEON for single precision FP">;
switch the flag for using NEON for SP floating point to a subtarget 'feature'. Re-commit. This time complete with testsuite updates. llvm-svn: 99570
2010-03-26 07:47:34 +08:00
Change -prefer-32bit-thumb to attribute -mattr=+32bit instead to disable more 32-bit to 16-bit optimizations. llvm-svn: 110584
2010-08-10 02:35:19 +08:00
// Disable 32-bit to 16-bit narrowing for experimentation.
def FeaturePref32BitThumb : SubtargetFeature<"32bit", "Pref32BitThumb", "true",
"Prefer 32-bit Thumb instrs">;
switch the use-vml[as] instructions flag to a subtarget 'feature' llvm-svn: 99565
2010-03-26 07:11:16 +08:00
Avoid some 's' 16-bit instruction which partially update CPSR (and add false dependency) when it isn't dependent on last CPSR defining instruction. rdar://8928208 llvm-svn: 129773
2011-04-20 02:11:49 +08:00
/// Some instructions update CPSR partially, which can add false dependency for
/// out-of-order implementation, e.g. Cortex-A9, unless each individual bit is
/// mapped to a separate physical register. Avoid partial CPSR update for these
/// processors.
def FeatureAvoidPartialCPSR : SubtargetFeature<"avoid-partial-cpsr",
"AvoidCPSRPartialUpdate", "true",
"Avoid CPSR partial update for OOO execution">;
On some ARM cpus, flags setting movs with shifter operand, i.e. lsl, lsr, asr, are more expensive than the non-flag setting variant. Teach thumb2 size reduction pass to avoid generating them unless we are optimizing for size. rdar://12892707 llvm-svn: 170728
2012-12-21 03:59:30 +08:00
def FeatureAvoidMOVsShOp : SubtargetFeature<"avoid-movs-shop",
"AvoidMOVsShifterOperand", "true",
"Avoid movs instructions with shifter operand">;
Re-commit r151623 with fix. Only issue special no-return calls if it's a direct call. llvm-svn: 151645
2012-02-29 02:51:51 +08:00
// Some processors perform return stack prediction. CodeGen should avoid issue
// "normal" call instructions to callees which do not return.
def FeatureHasRAS : SubtargetFeature<"ras", "HasRAS", "true",
"Has return address stack">;
ARMv7M vs. ARMv7E-M support. The DSP instructions in the Thumb2 instruction set are an optional extension in the Cortex-M* archtitecture. When present, the implementation is considered an "ARMv7E-M implementation," and when not, an "ARMv7-M implementation." Add a subtarget feature hook for the v7e-m instructions and hook it up. The cortex-m3 cpu is an example of a v7m implementation, while the cortex-m4 is a v7e-m implementation. rdar://9572992 llvm-svn: 134261
2011-07-02 05:12:19 +08:00
/// Some M architectures don't have the DSP extension (v7E-M vs. v7M)
def FeatureDSPThumb2 : SubtargetFeature<"t2dsp", "Thumb2DSP", "true",
Remove stray fullstop. llvm-svn: 138589
2011-08-26 05:46:20 +08:00
"Supports v7 DSP instructions in Thumb2">;
ARMv7M vs. ARMv7E-M support. The DSP instructions in the Thumb2 instruction set are an optional extension in the Cortex-M* archtitecture. When present, the implementation is considered an "ARMv7E-M implementation," and when not, an "ARMv7-M implementation." Add a subtarget feature hook for the v7e-m instructions and hook it up. The cortex-m3 cpu is an example of a v7m implementation, while the cortex-m4 is a v7e-m implementation. rdar://9572992 llvm-svn: 134261
2011-07-02 05:12:19 +08:00
Fix preload instruction isel. Only v7 supports pli, and only v7 with mp extension supports pldw. Add subtarget attribute to denote mp extension support and legalize illegal ones to nothing. llvm-svn: 118160
2010-11-03 14:34:55 +08:00
// Multiprocessing extension.
def FeatureMP : SubtargetFeature<"mp", "HasMPExtension", "true",
"Supports Multiprocessing extension">;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) llvm-svn: 110795
2010-08-11 14:51:54 +08:00
[ARM] Add Virtualization subtarget feature and more build attributes in this area Add a Virtualization ARM subtarget feature along with adding proper build attribute emission for Tag_Virtualization_use (encodes Virtualization and TrustZone) and Tag_MPextension_use. Also rework test/CodeGen/ARM/2010-10-19-mc-elf-objheader.ll testcase to something that is more maintainable. This changes the focus of this testcase away from testing CPU defaults (which is tested elsewhere), onto specifically testing that attributes are encoded correctly. llvm-svn: 193859
2013-11-01 21:27:35 +08:00
// Virtualization extension - requires HW divide (ARMv7-AR ARMARM - 4.4.8).
def FeatureVirtualization : SubtargetFeature<"virtualization",
"HasVirtualization", "true",
"Supports Virtualization extension",
[FeatureHWDiv, FeatureHWDivARM]>;
[ARM] Split A/R class into separate subtarget features. Patch by Bradley Smith. llvm-svn: 191202
2013-09-23 22:26:15 +08:00
// M-series ISA
def FeatureMClass : SubtargetFeature<"mclass", "ARMProcClass", "MClass",
Check in a patch that has already been code reviewed by Owen that I'd forgotten to commit. Build on previous patches to successfully distinguish between an M-series and A/R-series MSR and MRS instruction. These take different mask names and have a *slightly* different opcode format. Add decoder and disassembler tests. Improvement on the previous patch - successfully distinguish between valid v6m and v7m masks (one is a subset of the other). The patch had to be edited slightly to apply to ToT. llvm-svn: 140696
2011-09-28 22:21:38 +08:00
"Is microcontroller profile ('M' series)">;
[ARM] Split A/R class into separate subtarget features. Patch by Bradley Smith. llvm-svn: 191202
2013-09-23 22:26:15 +08:00
// R-series ISA
def FeatureRClass : SubtargetFeature<"rclass", "ARMProcClass", "RClass",
"Is realtime profile ('R' series)">;
// A-series ISA
def FeatureAClass : SubtargetFeature<"aclass", "ARMProcClass", "AClass",
"Is application profile ('A' series)">;
Add a special ARM trap encoding for NaCl. More details in this thread: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130128/163783.html Patch by JF Bastien llvm-svn: 173943
2013-01-31 00:30:19 +08:00
// Special TRAP encoding for NaCl, which looks like a TRAP in Thumb too.
// See ARMInstrInfo.td for details.
def FeatureNaClTrap : SubtargetFeature<"nacl-trap", "UseNaClTrap", "true",
"NaCl trap">;
Sink feature IsThumb into MC layer. llvm-svn: 134608
2011-07-07 16:26:46 +08:00
// ARM ISAs.
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def HasV4TOps : SubtargetFeature<"v4t", "HasV4TOps", "true",
Sink feature IsThumb into MC layer. llvm-svn: 134608
2011-07-07 16:26:46 +08:00
"Support ARM v4T instructions">;
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def HasV5TOps : SubtargetFeature<"v5t", "HasV5TOps", "true",
Sink feature IsThumb into MC layer. llvm-svn: 134608
2011-07-07 16:26:46 +08:00
"Support ARM v5T instructions",
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
[HasV4TOps]>;
def HasV5TEOps : SubtargetFeature<"v5te", "HasV5TEOps", "true",
Sink feature IsThumb into MC layer. llvm-svn: 134608
2011-07-07 16:26:46 +08:00
"Support ARM v5TE, v5TEj, and v5TExp instructions",
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
[HasV5TOps]>;
def HasV6Ops : SubtargetFeature<"v6", "HasV6Ops", "true",
Sink feature IsThumb into MC layer. llvm-svn: 134608
2011-07-07 16:26:46 +08:00
"Support ARM v6 instructions",
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
[HasV5TEOps]>;
ARM: allow cortex-m0 to use hint instructions The hint instructions ("nop", "yield", etc) are mostly Thumb2-only, but have been ported across to the v6M architecture. Fortunately, v6M seems to sit nicely between v6 (thumb-1 only) and v6T2, so we can add a feature for it fairly easily. rdar://problem/15144406 llvm-svn: 192097
2013-10-07 19:10:47 +08:00
def HasV6MOps : SubtargetFeature<"v6m", "HasV6MOps", "true",
"Support ARM v6M instructions",
[HasV6Ops]>;
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def HasV6T2Ops : SubtargetFeature<"v6t2", "HasV6T2Ops", "true",
Sink feature IsThumb into MC layer. llvm-svn: 134608
2011-07-07 16:26:46 +08:00
"Support ARM v6t2 instructions",
ARM: allow cortex-m0 to use hint instructions The hint instructions ("nop", "yield", etc) are mostly Thumb2-only, but have been ported across to the v6M architecture. Fortunately, v6M seems to sit nicely between v6 (thumb-1 only) and v6T2, so we can add a feature for it fairly easily. rdar://problem/15144406 llvm-svn: 192097
2013-10-07 19:10:47 +08:00
[HasV6MOps, FeatureThumb2]>;
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def HasV7Ops : SubtargetFeature<"v7", "HasV7Ops", "true",
Sink feature IsThumb into MC layer. llvm-svn: 134608
2011-07-07 16:26:46 +08:00
"Support ARM v7 instructions",
ARM: Add Performance Monitor Extensions feature Performance monitors, including a basic cycle counter, are an official extension in the ARMv7 specification. This adds support for enabling and disabling them, orthogonally from CPU selection. rdar://problem/13939186 llvm-svn: 182602
2013-05-24 03:11:14 +08:00
[HasV6T2Ops, FeaturePerfMon]>;
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
def HasV8Ops : SubtargetFeature<"v8", "HasV8Ops", "true",
"Support ARM v8 instructions",
[ARM] Add Virtualization subtarget feature and more build attributes in this area Add a Virtualization ARM subtarget feature along with adding proper build attribute emission for Tag_Virtualization_use (encodes Virtualization and TrustZone) and Tag_MPextension_use. Also rework test/CodeGen/ARM/2010-10-19-mc-elf-objheader.ll testcase to something that is more maintainable. This changes the focus of this testcase away from testing CPU defaults (which is tested elsewhere), onto specifically testing that attributes are encoded correctly. llvm-svn: 193859
2013-11-01 21:27:35 +08:00
[HasV7Ops, FeatureVirtualization,
FeatureMP]>;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) llvm-svn: 110795
2010-08-11 14:51:54 +08:00
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
//===----------------------------------------------------------------------===//
// ARM Processors supported.
//
Latency information for ARM v6. It's rough and not yet hooked up. Right now we are only using branch latency to determine if-conversion limits. llvm-svn: 73747
2009-06-19 09:51:50 +08:00
include "ARMSchedule.td"
Teach if-converter to be more careful with predicating instructions that would take multiple cycles to decode. For the current if-converter clients (actually only ARM), the instructions that are predicated on false are not nops. They would still take machine cycles to decode. Micro-coded instructions such as LDM / STM can potentially take multiple cycles to decode. If-converter should take treat them as non-micro-coded simple instructions. llvm-svn: 113570
2010-09-10 09:29:16 +08:00
// ARM processor families.
Add cortex-a5 subtarget to the supported ARM architectures llvm-svn: 168933
2012-11-30 03:48:01 +08:00
def ProcA5 : SubtargetFeature<"a5", "ARMProcFamily", "CortexA5",
"Cortex-A5 ARM processors",
Avoid NEON SP-FP unless unsafe-math or Darwin NEON is not IEEE 754 compliant, so we should avoid lowering single-precision floating point operations with NEON unless unsafe-math is turned on. The equivalent VFP instructions are IEEE 754 compliant, but in some cores they're much slower, so some archs/OSs might still request it to be on by default, such as Swift and Darwin. llvm-svn: 177651
2013-03-22 02:47:47 +08:00
[FeatureSlowFPBrcc, FeatureHasSlowFPVMLx,
ARM: Make "SMC" instructions conditional on new TrustZone architecture feature. These instructions aren't universally available, but depend on a specific extension to the normal ARM architecture (rather than, say, v6/v7/...) so a new feature is appropriate. This also enables the feature by default on A-class cores which usually have these extensions, to avoid breaking existing code and act as a sensible default. llvm-svn: 179171
2013-04-10 20:08:35 +08:00
FeatureVMLxForwarding, FeatureT2XtPk,
[ARM] Enable FeatureMP for Cortex-A5 by default. Patch by Oliver Stannard. llvm-svn: 195640
2013-11-25 21:17:15 +08:00
FeatureTrustZone, FeatureMP]>;
[ARM] add basic Cortex-A7 support to LLVM backend llvm-svn: 195358
2013-11-21 22:03:21 +08:00
def ProcA7 : SubtargetFeature<"a7", "ARMProcFamily", "CortexA7",
"Cortex-A7 ARM processors",
[FeatureSlowFPBrcc, FeatureHasSlowFPVMLx,
FeatureVMLxForwarding, FeatureT2XtPk,
FeatureVFP4, FeatureMP,
FeatureHWDiv, FeatureHWDivARM,
FeatureTrustZone, FeatureVirtualization]>;
Teach if-converter to be more careful with predicating instructions that would take multiple cycles to decode. For the current if-converter clients (actually only ARM), the instructions that are predicated on false are not nops. They would still take machine cycles to decode. Micro-coded instructions such as LDM / STM can potentially take multiple cycles to decode. If-converter should take treat them as non-micro-coded simple instructions. llvm-svn: 113570
2010-09-10 09:29:16 +08:00
def ProcA8 : SubtargetFeature<"a8", "ARMProcFamily", "CortexA8",
"Cortex-A8 ARM processors",
Avoid NEON SP-FP unless unsafe-math or Darwin NEON is not IEEE 754 compliant, so we should avoid lowering single-precision floating point operations with NEON unless unsafe-math is turned on. The equivalent VFP instructions are IEEE 754 compliant, but in some cores they're much slower, so some archs/OSs might still request it to be on by default, such as Swift and Darwin. llvm-svn: 177651
2013-03-22 02:47:47 +08:00
[FeatureSlowFPBrcc, FeatureHasSlowFPVMLx,
ARM: Make "SMC" instructions conditional on new TrustZone architecture feature. These instructions aren't universally available, but depend on a specific extension to the normal ARM architecture (rather than, say, v6/v7/...) so a new feature is appropriate. This also enables the feature by default on A-class cores which usually have these extensions, to avoid breaking existing code and act as a sensible default. llvm-svn: 179171
2013-04-10 20:08:35 +08:00
FeatureVMLxForwarding, FeatureT2XtPk,
FeatureTrustZone]>;
Teach if-converter to be more careful with predicating instructions that would take multiple cycles to decode. For the current if-converter clients (actually only ARM), the instructions that are predicated on false are not nops. They would still take machine cycles to decode. Micro-coded instructions such as LDM / STM can potentially take multiple cycles to decode. If-converter should take treat them as non-micro-coded simple instructions. llvm-svn: 113570
2010-09-10 09:29:16 +08:00
def ProcA9 : SubtargetFeature<"a9", "ARMProcFamily", "CortexA9",
Code clean up. llvm-svn: 120965
2010-12-06 07:03:45 +08:00
"Cortex-A9 ARM processors",
This patch combines several changes from Evan Cheng for rdar://8659675. Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Enable these fp vmlx codegen changes for Cortex-A9. llvm-svn: 129775
2011-04-20 02:11:57 +08:00
[FeatureVMLxForwarding,
Avoid some 's' 16-bit instruction which partially update CPSR (and add false dependency) when it isn't dependent on last CPSR defining instruction. rdar://8928208 llvm-svn: 129773
2011-04-20 02:11:49 +08:00
FeatureT2XtPk, FeatureFP16,
ARM: Make "SMC" instructions conditional on new TrustZone architecture feature. These instructions aren't universally available, but depend on a specific extension to the normal ARM architecture (rather than, say, v6/v7/...) so a new feature is appropriate. This also enables the feature by default on A-class cores which usually have these extensions, to avoid breaking existing code and act as a sensible default. llvm-svn: 179171
2013-04-10 20:08:35 +08:00
FeatureAvoidPartialCPSR,
FeatureTrustZone]>;
Add LLVM support for Swift. llvm-svn: 164899
2012-09-30 05:43:49 +08:00
def ProcSwift : SubtargetFeature<"swift", "ARMProcFamily", "Swift",
"Swift ARM processors",
[FeatureNEONForFP, FeatureT2XtPk,
FeatureVFP4, FeatureMP, FeatureHWDiv,
FeatureHWDivARM, FeatureAvoidPartialCPSR,
On some ARM cpus, flags setting movs with shifter operand, i.e. lsl, lsr, asr, are more expensive than the non-flag setting variant. Teach thumb2 size reduction pass to avoid generating them unless we are optimizing for size. rdar://12892707 llvm-svn: 170728
2012-12-21 03:59:30 +08:00
FeatureAvoidMOVsShOp,
ARM: Make "SMC" instructions conditional on new TrustZone architecture feature. These instructions aren't universally available, but depend on a specific extension to the normal ARM architecture (rather than, say, v6/v7/...) so a new feature is appropriate. This also enables the feature by default on A-class cores which usually have these extensions, to avoid breaking existing code and act as a sensible default. llvm-svn: 179171
2013-04-10 20:08:35 +08:00
FeatureHasSlowFPVMLx, FeatureTrustZone]>;
Add support for Cortex-A12. Patch by Oliver Stannard! llvm-svn: 195448
2013-11-22 19:53:16 +08:00
def ProcA12 : SubtargetFeature<"a12", "ARMProcFamily", "CortexA12",
"Cortex-A12 ARM processors",
[FeatureVMLxForwarding,
FeatureT2XtPk, FeatureVFP4,
FeatureHWDiv, FeatureHWDivARM,
FeatureAvoidPartialCPSR,
FeatureVirtualization,
FeatureTrustZone]>;
Add LLVM support for Swift. llvm-svn: 164899
2012-09-30 05:43:49 +08:00
This patch introduces A15 as a target in LLVM. llvm-svn: 163803
2012-09-13 23:05:10 +08:00
// FIXME: It has not been determined if A15 has these features.
def ProcA15 : SubtargetFeature<"a15", "ARMProcFamily", "CortexA15",
"Cortex-A15 ARM processors",
Remove the now redundant FeatureFP16 from the Cortex-A15 feature list. It was made redundant when FeatureVFP4 was added which implies FP16. llvm-svn: 187985
2013-08-08 23:47:33 +08:00
[FeatureT2XtPk, FeatureVFP4,
Add hardware division as a default feature on Cortex-A15. Also add test cases to check this, and change diagnostics for the hwdiv-arm feature to something useful. llvm-svn: 192963
2013-10-18 18:18:40 +08:00
FeatureMP, FeatureHWDiv, FeatureHWDivARM,
ARM: Make "SMC" instructions conditional on new TrustZone architecture feature. These instructions aren't universally available, but depend on a specific extension to the normal ARM architecture (rather than, say, v6/v7/...) so a new feature is appropriate. This also enables the feature by default on A-class cores which usually have these extensions, to avoid breaking existing code and act as a sensible default. llvm-svn: 179171
2013-04-10 20:08:35 +08:00
FeatureAvoidPartialCPSR,
[ARM] Add Virtualization subtarget feature and more build attributes in this area Add a Virtualization ARM subtarget feature along with adding proper build attribute emission for Tag_Virtualization_use (encodes Virtualization and TrustZone) and Tag_MPextension_use. Also rework test/CodeGen/ARM/2010-10-19-mc-elf-objheader.ll testcase to something that is more maintainable. This changes the focus of this testcase away from testing CPU defaults (which is tested elsewhere), onto specifically testing that attributes are encoded correctly. llvm-svn: 193859
2013-11-01 21:27:35 +08:00
FeatureTrustZone, FeatureVirtualization]>;
Add subtarget feature support for Cortex-A53 Some previous implicit defaults have changed, for example FP and NEON are now on by default. llvm-svn: 192590
2013-10-14 21:16:57 +08:00
def ProcA53 : SubtargetFeature<"a53", "ARMProcFamily", "CortexA53",
"Cortex-A53 ARM processors",
[ARM] Add Virtualization subtarget feature and more build attributes in this area Add a Virtualization ARM subtarget feature along with adding proper build attribute emission for Tag_Virtualization_use (encodes Virtualization and TrustZone) and Tag_MPextension_use. Also rework test/CodeGen/ARM/2010-10-19-mc-elf-objheader.ll testcase to something that is more maintainable. This changes the focus of this testcase away from testing CPU defaults (which is tested elsewhere), onto specifically testing that attributes are encoded correctly. llvm-svn: 193859
2013-11-01 21:27:35 +08:00
[FeatureHWDiv, FeatureHWDivARM,
Add subtarget feature support for Cortex-A53 Some previous implicit defaults have changed, for example FP and NEON are now on by default. llvm-svn: 192590
2013-10-14 21:16:57 +08:00
FeatureTrustZone, FeatureT2XtPk,
ARM: Add subtarget feature for CRC Adds a subtarget feature for the CRC instructions (optional in v8-A) to the ARM (32-bit) backend. Differential Revision: http://llvm-reviews.chandlerc.com/D2036 llvm-svn: 193599
2013-10-29 17:47:35 +08:00
FeatureCrypto, FeatureCRC]>;
Add subtarget feature support for Cortex-A53 Some previous implicit defaults have changed, for example FP and NEON are now on by default. llvm-svn: 192590
2013-10-14 21:16:57 +08:00
Add Cortex-A57 support llvm-svn: 192591
2013-10-14 21:17:07 +08:00
def ProcA57 : SubtargetFeature<"a57", "ARMProcFamily", "CortexA57",
"Cortex-A57 ARM processors",
[ARM] Add Virtualization subtarget feature and more build attributes in this area Add a Virtualization ARM subtarget feature along with adding proper build attribute emission for Tag_Virtualization_use (encodes Virtualization and TrustZone) and Tag_MPextension_use. Also rework test/CodeGen/ARM/2010-10-19-mc-elf-objheader.ll testcase to something that is more maintainable. This changes the focus of this testcase away from testing CPU defaults (which is tested elsewhere), onto specifically testing that attributes are encoded correctly. llvm-svn: 193859
2013-11-01 21:27:35 +08:00
[FeatureHWDiv, FeatureHWDivARM,
Add Cortex-A57 support llvm-svn: 192591
2013-10-14 21:17:07 +08:00
FeatureTrustZone, FeatureT2XtPk,
ARM: Add subtarget feature for CRC Adds a subtarget feature for the CRC instructions (optional in v8-A) to the ARM (32-bit) backend. Differential Revision: http://llvm-reviews.chandlerc.com/D2036 llvm-svn: 193599
2013-10-29 17:47:35 +08:00
FeatureCrypto, FeatureCRC]>;
Add Cortex-A57 support llvm-svn: 192591
2013-10-14 21:17:07 +08:00
Add ARM cortex-r5 subtarget. llvm-svn: 170840
2012-12-21 12:35:05 +08:00
def ProcR5 : SubtargetFeature<"r5", "ARMProcFamily", "CortexR5",
"Cortex-R5 ARM processors",
Cortex-R5 can issue Thumb2 integer division instructions. llvm-svn: 183275
2013-06-05 06:52:09 +08:00
[FeatureSlowFPBrcc,
FeatureHWDiv, FeatureHWDivARM,
Add ARM cortex-r5 subtarget. llvm-svn: 170840
2012-12-21 12:35:05 +08:00
FeatureHasSlowFPVMLx,
FeatureAvoidPartialCPSR,
FeatureT2XtPk]>;
Teach if-converter to be more careful with predicating instructions that would take multiple cycles to decode. For the current if-converter clients (actually only ARM), the instructions that are predicated on false are not nops. They would still take machine cycles to decode. Micro-coded instructions such as LDM / STM can potentially take multiple cycles to decode. If-converter should take treat them as non-micro-coded simple instructions. llvm-svn: 113570
2010-09-10 09:29:16 +08:00
Added support for mcpu krait - krait processor currently modeled with the same features as A9. - Krait processor additionally has VFP4 (fused multiply add/sub) and hardware division features enabled. - krait has currently the same Schedule model as A9 - krait cpu flag is not recognized by the GNU assembler yet, it is replaced with march=armv7-a to avoid a lower march from being used. llvm-svn: 196619
2013-12-07 06:48:17 +08:00
// FIXME: krait has currently the same features as A9
// plus VFP4 and hardware division features.
def ProcKrait : SubtargetFeature<"krait", "ARMProcFamily", "Krait",
"Qualcomm ARM processors",
[FeatureVMLxForwarding,
FeatureT2XtPk, FeatureFP16,
FeatureAvoidPartialCPSR,
FeatureTrustZone,
FeatureVFP4,
FeatureHWDiv,
FeatureHWDivARM]>;
Make the ARM ABI selectable via SubtargetFeature. This patch makes it possible to select the ABI with -mattr. It will be used to forward clang's -target-abi option to llvm's CodeGen. llvm-svn: 198304
2014-01-02 21:40:08 +08:00
def FeatureAPCS : SubtargetFeature<"apcs", "TargetABI", "ARM_ABI_APCS",
"Use the APCS ABI">;
def FeatureAAPCS : SubtargetFeature<"aapcs", "TargetABI", "ARM_ABI_AAPCS",
"Use the AAPCS ABI">;
Latency information for ARM v6. It's rough and not yet hooked up. Right now we are only using branch latency to determine if-conversion limits. llvm-svn: 73747
2009-06-19 09:51:50 +08:00
class ProcNoItin<string Name, list<SubtargetFeature> Features>
Use "NoItineraries" for processors with no itineraries. This makes it explicit when ScoreboardHazardRecognizer will be used. "GenericItineraries" would only make sense if it contained real itinerary values and still required ScoreboardHazardRecognizer. llvm-svn: 158963
2012-06-22 11:58:51 +08:00
: Processor<Name, NoItineraries, Features>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
// V4 Processors.
Latency information for ARM v6. It's rough and not yet hooked up. Right now we are only using branch latency to determine if-conversion limits. llvm-svn: 73747
2009-06-19 09:51:50 +08:00
def : ProcNoItin<"generic", []>;
def : ProcNoItin<"arm8", []>;
def : ProcNoItin<"arm810", []>;
def : ProcNoItin<"strongarm", []>;
def : ProcNoItin<"strongarm110", []>;
def : ProcNoItin<"strongarm1100", []>;
def : ProcNoItin<"strongarm1110", []>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
// V4T Processors.
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def : ProcNoItin<"arm7tdmi", [HasV4TOps]>;
def : ProcNoItin<"arm7tdmi-s", [HasV4TOps]>;
def : ProcNoItin<"arm710t", [HasV4TOps]>;
def : ProcNoItin<"arm720t", [HasV4TOps]>;
def : ProcNoItin<"arm9", [HasV4TOps]>;
def : ProcNoItin<"arm9tdmi", [HasV4TOps]>;
def : ProcNoItin<"arm920", [HasV4TOps]>;
def : ProcNoItin<"arm920t", [HasV4TOps]>;
def : ProcNoItin<"arm922t", [HasV4TOps]>;
def : ProcNoItin<"arm940t", [HasV4TOps]>;
def : ProcNoItin<"ep9312", [HasV4TOps]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
// V5T Processors.
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def : ProcNoItin<"arm10tdmi", [HasV5TOps]>;
def : ProcNoItin<"arm1020t", [HasV5TOps]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
// V5TE Processors.
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def : ProcNoItin<"arm9e", [HasV5TEOps]>;
def : ProcNoItin<"arm926ej-s", [HasV5TEOps]>;
def : ProcNoItin<"arm946e-s", [HasV5TEOps]>;
def : ProcNoItin<"arm966e-s", [HasV5TEOps]>;
def : ProcNoItin<"arm968e-s", [HasV5TEOps]>;
def : ProcNoItin<"arm10e", [HasV5TEOps]>;
def : ProcNoItin<"arm1020e", [HasV5TEOps]>;
def : ProcNoItin<"arm1022e", [HasV5TEOps]>;
def : ProcNoItin<"xscale", [HasV5TEOps]>;
def : ProcNoItin<"iwmmxt", [HasV5TEOps]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
// V6 Processors.
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def : Processor<"arm1136j-s", ARMV6Itineraries, [HasV6Ops]>;
def : Processor<"arm1136jf-s", ARMV6Itineraries, [HasV6Ops, FeatureVFP2,
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
FeatureHasSlowFPVMLx]>;
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def : Processor<"arm1176jz-s", ARMV6Itineraries, [HasV6Ops]>;
def : Processor<"arm1176jzf-s", ARMV6Itineraries, [HasV6Ops, FeatureVFP2,
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
FeatureHasSlowFPVMLx]>;
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def : Processor<"mpcorenovfp", ARMV6Itineraries, [HasV6Ops]>;
def : Processor<"mpcore", ARMV6Itineraries, [HasV6Ops, FeatureVFP2,
Making use of VFP / NEON floating point multiply-accumulate / subtraction is difficult on current ARM implementations for a few reasons. 1. Even though a single vmla has latency that is one cycle shorter than a pair of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause additional pipeline stall. So it's frequently better to single codegen vmul + vadd. 2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to stall for 4 cycles. We need to schedule them apart. 3. A vmla followed vmla is a special case. Obvious issuing back to back RAW vmla + vmla is very bad. But this isn't ideal either: vmul vadd vmla Instead, we want to expand the second vmla: vmla vmul vadd Even with the 4 cycle vmul stall, the second sequence is still 2 cycles faster. Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough but it isn't the optimial solution. This patch attempts to make it possible to use vmla / vmls in cases where it is profitable. A. Add missing isel predicates which cause vmla to be codegen'ed. B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to compute a fmul and a fmla. C. Add additional isel checks for vmla, avoid cases where vmla is feeding into fp instructions (except for the #3 exceptional case). D. Add ARM hazard recognizer to model the vmla / vmls hazards. E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the vmla / vmls will trigger one of the special hazards. Work in progress, only A+B are enabled. llvm-svn: 120960
2010-12-06 06:04:16 +08:00
FeatureHasSlowFPVMLx]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
Add Cortex-M0 support. It's a ARMv6m device (no ARM mode) with some 32-bit instructions: dmb, dsb, isb, msr, and mrs. llvm-svn: 110786
2010-08-11 14:30:38 +08:00
// V6M Processors.
ARM: allow cortex-m0 to use hint instructions The hint instructions ("nop", "yield", etc) are mostly Thumb2-only, but have been ported across to the v6M architecture. Fortunately, v6M seems to sit nicely between v6 (thumb-1 only) and v6T2, so we can add a feature for it fairly easily. rdar://problem/15144406 llvm-svn: 192097
2013-10-07 19:10:47 +08:00
def : Processor<"cortex-m0", ARMV6Itineraries, [HasV6MOps, FeatureNoARM,
Check in a patch that has already been code reviewed by Owen that I'd forgotten to commit. Build on previous patches to successfully distinguish between an M-series and A/R-series MSR and MRS instruction. These take different mask names and have a *slightly* different opcode format. Add decoder and disassembler tests. Improvement on the previous patch - successfully distinguish between valid v6m and v7m masks (one is a subset of the other). The patch had to be edited slightly to apply to ToT. llvm-svn: 140696
2011-09-28 22:21:38 +08:00
FeatureDB, FeatureMClass]>;
Add Cortex-M0 support. It's a ARMv6m device (no ARM mode) with some 32-bit instructions: dmb, dsb, isb, msr, and mrs. llvm-svn: 110786
2010-08-11 14:30:38 +08:00
Separate V6 from V6T2 since the latter has some extra nice instructions llvm-svn: 73085
2009-06-09 05:20:36 +08:00
// V6T2 Processors.
Fix a bug introduced during refactoring a couple of months ago. Cortex-M3 does not support Thumb2 dsp instructions. rdar://10152911. llvm-svn: 140181
2011-09-21 05:38:18 +08:00
def : Processor<"arm1156t2-s", ARMV6Itineraries, [HasV6T2Ops,
FeatureDSPThumb2]>;
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def : Processor<"arm1156t2f-s", ARMV6Itineraries, [HasV6T2Ops, FeatureVFP2,
Fix a bug introduced during refactoring a couple of months ago. Cortex-M3 does not support Thumb2 dsp instructions. rdar://10152911. llvm-svn: 140181
2011-09-21 05:38:18 +08:00
FeatureHasSlowFPVMLx,
FeatureDSPThumb2]>;
Add placeholder for thumb2 stuff llvm-svn: 72593
2009-05-30 07:41:08 +08:00
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
// V7a Processors.
Add cortex-a5 subtarget to the supported ARM architectures llvm-svn: 168933
2012-11-30 03:48:01 +08:00
// FIXME: A5 has currently the same Schedule model as A8
def : ProcessorModel<"cortex-a5", CortexA8Model,
[ProcA5, HasV7Ops, FeatureNEON, FeatureDB,
FeatureVFP4, FeatureDSPThumb2,
[ARM] Split A/R class into separate subtarget features. Patch by Bradley Smith. llvm-svn: 191202
2013-09-23 22:26:15 +08:00
FeatureHasRAS, FeatureAClass]>;
[ARM] add basic Cortex-A7 support to LLVM backend llvm-svn: 195358
2013-11-21 22:03:21 +08:00
def : ProcessorModel<"cortex-a7", CortexA8Model,
[ProcA7, HasV7Ops, FeatureNEON, FeatureDB,
FeatureDSPThumb2, FeatureHasRAS,
FeatureAClass]>;
I'm introducing a new machine model to simultaneously allow simple subtarget CPU descriptions and support new features of MachineScheduler. MachineModel has three categories of data: 1) Basic properties for coarse grained instruction cost model. 2) Scheduler Read/Write resources for simple per-opcode and operand cost model (TBD). 3) Instruction itineraties for detailed per-cycle reservation tables. These will all live side-by-side. Any subtarget can use any combination of them. Instruction itineraries will not change in the near term. In the long run, I expect them to only be relevant for in-order VLIW machines that have complex contraints and require a precise scheduling/bundling model. Once itineraries are only actively used by VLIW-ish targets, they could be replaced by something more appropriate for those targets. This tablegen backend rewrite sets things up for introducing MachineModel type #2: per opcode/operand cost model. llvm-svn: 159891
2012-07-07 12:00:00 +08:00
def : ProcessorModel<"cortex-a8", CortexA8Model,
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
[ProcA8, HasV7Ops, FeatureNEON, FeatureDB,
[ARM] Split A/R class into separate subtarget features. Patch by Bradley Smith. llvm-svn: 191202
2013-09-23 22:26:15 +08:00
FeatureDSPThumb2, FeatureHasRAS,
FeatureAClass]>;
I'm introducing a new machine model to simultaneously allow simple subtarget CPU descriptions and support new features of MachineScheduler. MachineModel has three categories of data: 1) Basic properties for coarse grained instruction cost model. 2) Scheduler Read/Write resources for simple per-opcode and operand cost model (TBD). 3) Instruction itineraties for detailed per-cycle reservation tables. These will all live side-by-side. Any subtarget can use any combination of them. Instruction itineraries will not change in the near term. In the long run, I expect them to only be relevant for in-order VLIW machines that have complex contraints and require a precise scheduling/bundling model. Once itineraries are only actively used by VLIW-ish targets, they could be replaced by something more appropriate for those targets. This tablegen backend rewrite sets things up for introducing MachineModel type #2: per opcode/operand cost model. llvm-svn: 159891
2012-07-07 12:00:00 +08:00
def : ProcessorModel<"cortex-a9", CortexA9Model,
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
[ProcA9, HasV7Ops, FeatureNEON, FeatureDB,
[ARM] Split A/R class into separate subtarget features. Patch by Bradley Smith. llvm-svn: 191202
2013-09-23 22:26:15 +08:00
FeatureDSPThumb2, FeatureHasRAS,
FeatureAClass]>;
I'm introducing a new machine model to simultaneously allow simple subtarget CPU descriptions and support new features of MachineScheduler. MachineModel has three categories of data: 1) Basic properties for coarse grained instruction cost model. 2) Scheduler Read/Write resources for simple per-opcode and operand cost model (TBD). 3) Instruction itineraties for detailed per-cycle reservation tables. These will all live side-by-side. Any subtarget can use any combination of them. Instruction itineraries will not change in the near term. In the long run, I expect them to only be relevant for in-order VLIW machines that have complex contraints and require a precise scheduling/bundling model. Once itineraries are only actively used by VLIW-ish targets, they could be replaced by something more appropriate for those targets. This tablegen backend rewrite sets things up for introducing MachineModel type #2: per opcode/operand cost model. llvm-svn: 159891
2012-07-07 12:00:00 +08:00
def : ProcessorModel<"cortex-a9-mp", CortexA9Model,
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
[ProcA9, HasV7Ops, FeatureNEON, FeatureDB,
Re-commit r151623 with fix. Only issue special no-return calls if it's a direct call. llvm-svn: 151645
2012-02-29 02:51:51 +08:00
FeatureDSPThumb2, FeatureMP,
[ARM] Split A/R class into separate subtarget features. Patch by Bradley Smith. llvm-svn: 191202
2013-09-23 22:26:15 +08:00
FeatureHasRAS, FeatureAClass]>;
Add support for Cortex-A12. Patch by Oliver Stannard! llvm-svn: 195448
2013-11-22 19:53:16 +08:00
// FIXME: A12 has currently the same Schedule model as A9
def : ProcessorModel<"cortex-a12", CortexA9Model,
[ProcA12, HasV7Ops, FeatureNEON, FeatureDB,
FeatureDSPThumb2, FeatureMP,
FeatureHasRAS, FeatureAClass]>;
This patch introduces A15 as a target in LLVM. llvm-svn: 163803
2012-09-13 23:05:10 +08:00
// FIXME: A15 has currently the same ProcessorModel as A9.
def : ProcessorModel<"cortex-a15", CortexA9Model,
[ProcA15, HasV7Ops, FeatureNEON, FeatureDB,
[ARM] Split A/R class into separate subtarget features. Patch by Bradley Smith. llvm-svn: 191202
2013-09-23 22:26:15 +08:00
FeatureDSPThumb2, FeatureHasRAS,
FeatureAClass]>;
Add support for Cortex-A12. Patch by Oliver Stannard! llvm-svn: 195448
2013-11-22 19:53:16 +08:00
ARM: add cyclone CPU with ZeroCycleZeroing feature. The Cyclone CPU is similar to swift for most LLVM purposes, but does have two preferred instructions for zeroing a VFP register. This teaches LLVM about them. llvm-svn: 205309
2014-04-01 21:22:02 +08:00
// FIXME: krait has currently the same Schedule model as A9
def : ProcessorModel<"krait", CortexA9Model,
[ProcKrait, HasV7Ops,
FeatureNEON, FeatureDB,
FeatureDSPThumb2, FeatureHasRAS,
FeatureAClass]>;
Add ARM cortex-r5 subtarget. llvm-svn: 170840
2012-12-21 12:35:05 +08:00
// FIXME: R5 has currently the same ProcessorModel as A8.
def : ProcessorModel<"cortex-r5", CortexA8Model,
[ProcR5, HasV7Ops, FeatureDB,
FeatureVFP3, FeatureDSPThumb2,
[ARM] Improve build attributes emission. llvm-svn: 192111
2013-10-08 00:55:23 +08:00
FeatureHasRAS, FeatureVFPOnlySP,
[arm] Implement eabi_attribute, cpu, and fpu directives. This commit allows the ARM integrated assembler to parse and assemble the code with .eabi_attribute, .cpu, and .fpu directives. To implement the feature, this commit moves the code from AttrEmitter to ARMTargetStreamers, and several new test cases related to cortex-m4, cortex-r5, and cortex-a15 are added. Besides, this commit also change the Subtarget->isFPOnlySP() to Subtarget->hasD16() to match the usage of .fpu directive. This commit changes the test cases: * Several .eabi_attribute directives in 2010-09-29-mc-asm-header-test.ll are removed because the .fpu directive already cover the functionality. * In the Cortex-A15 test case, the value for Tag_Advanced_SIMD_arch has be changed from 1 to 2, which is more precise. llvm-svn: 193524
2013-10-29 01:51:12 +08:00
FeatureD16, FeatureRClass]>;
Add Cortex-M0 support. It's a ARMv6m device (no ARM mode) with some 32-bit instructions: dmb, dsb, isb, msr, and mrs. llvm-svn: 110786
2010-08-11 14:30:38 +08:00
// V7M Processors.
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
def : ProcNoItin<"cortex-m3", [HasV7Ops,
FeatureThumb2, FeatureNoARM, FeatureDB,
Check in a patch that has already been code reviewed by Owen that I'd forgotten to commit. Build on previous patches to successfully distinguish between an M-series and A/R-series MSR and MRS instruction. These take different mask names and have a *slightly* different opcode format. Add decoder and disassembler tests. Improvement on the previous patch - successfully distinguish between valid v6m and v7m masks (one is a subset of the other). The patch had to be edited slightly to apply to ToT. llvm-svn: 140696
2011-09-28 22:21:38 +08:00
FeatureHWDiv, FeatureMClass]>;
Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests. llvm-svn: 134590
2011-07-07 11:55:05 +08:00
// V7EM Processors.
def : ProcNoItin<"cortex-m4", [HasV7Ops,
FeatureThumb2, FeatureNoARM, FeatureDB,
FeatureHWDiv, FeatureDSPThumb2,
Support fpv4 for ARM Cortex-M4. llvm-svn: 161163
2012-08-02 16:35:55 +08:00
FeatureT2XtPk, FeatureVFP4,
[arm] Implement eabi_attribute, cpu, and fpu directives. This commit allows the ARM integrated assembler to parse and assemble the code with .eabi_attribute, .cpu, and .fpu directives. To implement the feature, this commit moves the code from AttrEmitter to ARMTargetStreamers, and several new test cases related to cortex-m4, cortex-r5, and cortex-a15 are added. Besides, this commit also change the Subtarget->isFPOnlySP() to Subtarget->hasD16() to match the usage of .fpu directive. This commit changes the test cases: * Several .eabi_attribute directives in 2010-09-29-mc-asm-header-test.ll are removed because the .fpu directive already cover the functionality. * In the Cortex-A15 test case, the value for Tag_Advanced_SIMD_arch has be changed from 1 to 2, which is more precise. llvm-svn: 193524
2013-10-29 01:51:12 +08:00
FeatureVFPOnlySP, FeatureD16,
FeatureMClass]>;
Add ARMv7 architecture, Cortex processors and different FPU modes handling. llvm-svn: 72337
2009-05-24 03:51:43 +08:00
Add LLVM support for Swift. llvm-svn: 164899
2012-09-30 05:43:49 +08:00
// Swift uArch Processors.
def : ProcessorModel<"swift", SwiftModel,
[ProcSwift, HasV7Ops, FeatureNEON,
FeatureDB, FeatureDSPThumb2,
[ARM] Split A/R class into separate subtarget features. Patch by Bradley Smith. llvm-svn: 191202
2013-09-23 22:26:15 +08:00
FeatureHasRAS, FeatureAClass]>;
Add LLVM support for Swift. llvm-svn: 164899
2012-09-30 05:43:49 +08:00
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
// V8 Processors
Add subtarget feature support for Cortex-A53 Some previous implicit defaults have changed, for example FP and NEON are now on by default. llvm-svn: 192590
2013-10-14 21:16:57 +08:00
def : ProcNoItin<"cortex-a53", [ProcA53, HasV8Ops, FeatureAClass,
FeatureDB, FeatureFPARMv8,
FeatureNEON, FeatureDSPThumb2]>;
Add Cortex-A57 support llvm-svn: 192591
2013-10-14 21:17:07 +08:00
def : ProcNoItin<"cortex-a57", [ProcA57, HasV8Ops, FeatureAClass,
FeatureDB, FeatureFPARMv8,
FeatureNEON, FeatureDSPThumb2]>;
Add a subtarget feature 'v8' to the ARM backend. This allows for targeting the ARMv8 AArch32 variant. llvm-svn: 184967
2013-06-27 00:58:26 +08:00
ARM: add cyclone CPU with ZeroCycleZeroing feature. The Cyclone CPU is similar to swift for most LLVM purposes, but does have two preferred instructions for zeroing a VFP register. This teaches LLVM about them. llvm-svn: 205309
2014-04-01 21:22:02 +08:00
// Cyclone is very similar to swift
def : ProcessorModel<"cyclone", SwiftModel,
[ProcSwift, HasV8Ops, HasV7Ops,
FeatureCrypto, FeatureFPARMv8,
FeatureDB,FeatureDSPThumb2,
FeatureHasRAS, FeatureZCZeroing]>;
Added support for mcpu krait - krait processor currently modeled with the same features as A9. - Krait processor additionally has VFP4 (fused multiply add/sub) and hardware division features enabled. - krait has currently the same Schedule model as A9 - krait cpu flag is not recognized by the GNU assembler yet, it is replaced with march=armv7-a to avoid a lower march from being used. llvm-svn: 196619
2013-12-07 06:48:17 +08:00
added a skeleton of the ARM backend llvm-svn: 28301
2006-05-15 06:18:28 +08:00
//===----------------------------------------------------------------------===//
// Register File Description
//===----------------------------------------------------------------------===//
include "ARMRegisterInfo.td"
Use CallConvLower.h and TableGen descriptions of the calling conventions for ARM. Patch by Sandeep Patel. llvm-svn: 69371
2009-04-18 03:07:39 +08:00
include "ARMCallingConv.td"
added a skeleton of the ARM backend llvm-svn: 28301
2006-05-15 06:18:28 +08:00
//===----------------------------------------------------------------------===//
// Instruction Descriptions
//===----------------------------------------------------------------------===//
include "ARMInstrInfo.td"
Replace TSFlagsFields and TSFlagsShifts with a simpler TSFlags field. When a target instruction wants to set target-specific flags, it should simply set bits in the TSFlags bit vector defined in the Instruction TableGen class. This works well because TableGen resolves member references late: class I : Instruction { AddrMode AM = AddrModeNone; let TSFlags{3-0} = AM.Value; } let AM = AddrMode4 in def ADD : I; TSFlags gets the expected bits from AddrMode4 in this example. llvm-svn: 100384
2010-04-05 11:10:20 +08:00
def ARMInstrInfo : InstrInfo;
added a skeleton of the ARM backend llvm-svn: 28301
2006-05-15 06:18:28 +08:00
//===----------------------------------------------------------------------===//
// Declare the target which we are implementing
//===----------------------------------------------------------------------===//
def ARM : Target {
// Pull in Instruction Info:
let InstructionSet = ARMInstrInfo;
}