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

215 lines
9.6 KiB
TableGen
Raw Normal View History

fix emacs language spec's, patch by Edmund Grimley-Evans! llvm-svn: 111241
2010-08-18 00:20:04 +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
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.
//
Add ARMv7 architecture, Cortex processors and different FPU modes handling. llvm-svn: 72337
2009-05-24 03:51:43 +08:00
def FeatureVFP2 : SubtargetFeature<"vfp2", "ARMFPUType", "VFPv2",
Add placeholder for thumb2 stuff llvm-svn: 72593
2009-05-30 07:41:08 +08:00
"Enable VFP2 instructions">;
Add ARMv7 architecture, Cortex processors and different FPU modes handling. llvm-svn: 72337
2009-05-24 03:51:43 +08:00
def FeatureVFP3 : SubtargetFeature<"vfp3", "ARMFPUType", "VFPv3",
Add placeholder for thumb2 stuff llvm-svn: 72593
2009-05-30 07:41:08 +08:00
"Enable VFP3 instructions">;
Add ARMv7 architecture, Cortex processors and different FPU modes handling. llvm-svn: 72337
2009-05-24 03:51:43 +08:00
def FeatureNEON : SubtargetFeature<"neon", "ARMFPUType", "NEON",
Add placeholder for thumb2 stuff llvm-svn: 72593
2009-05-30 07:41:08 +08:00
"Enable NEON instructions">;
def FeatureThumb2 : SubtargetFeature<"thumb2", "ThumbMode", "Thumb2",
"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",
"Does not support ARM mode execution">;
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">;
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 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 backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
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">;
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
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 architectures.
def ArchV4T : SubtargetFeature<"v4t", "ARMArchVersion", "V4T",
"ARM v4T">;
def ArchV5T : SubtargetFeature<"v5t", "ARMArchVersion", "V5T",
"ARM v5T">;
def ArchV5TE : SubtargetFeature<"v5te", "ARMArchVersion", "V5TE",
"ARM v5TE, v5TEj, v5TExp">;
def ArchV6 : SubtargetFeature<"v6", "ARMArchVersion", "V6",
"ARM v6">;
def ArchV6M : SubtargetFeature<"v6m", "ARMArchVersion", "V6M",
"ARM v6m",
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
[FeatureNoARM, FeatureDB]>;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) llvm-svn: 110795
2010-08-11 14:51:54 +08:00
def ArchV6T2 : SubtargetFeature<"v6t2", "ARMArchVersion", "V6T2",
ArchV6T2, V7A, and V7M implies Thumb2; Archv7A implies NEON. llvm-svn: 110796
2010-08-11 14:57:53 +08:00
"ARM v6t2",
[FeatureThumb2]>;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) llvm-svn: 110795
2010-08-11 14:51:54 +08:00
def ArchV7A : SubtargetFeature<"v7a", "ARMArchVersion", "V7A",
"ARM v7A",
ArchV6T2, V7A, and V7M implies Thumb2; Archv7A implies NEON. llvm-svn: 110796
2010-08-11 14:57:53 +08:00
[FeatureThumb2, FeatureNEON, FeatureDB]>;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) llvm-svn: 110795
2010-08-11 14:51:54 +08:00
def ArchV7M : SubtargetFeature<"v7m", "ARMArchVersion", "V7M",
"ARM v7M",
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
[FeatureThumb2, FeatureNoARM, FeatureDB,
FeatureHWDiv]>;
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.
def ProcOthers : SubtargetFeature<"others", "ARMProcFamily", "Others",
"One of the other ARM processor families">;
def ProcA8 : SubtargetFeature<"a8", "ARMProcFamily", "CortexA8",
"Cortex-A8 ARM processors",
[FeatureSlowFPBrcc, FeatureNEONForFP]>;
def ProcA9 : SubtargetFeature<"a9", "ARMProcFamily", "CortexA9",
"Cortex-A9 ARM 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
class ProcNoItin<string Name, list<SubtargetFeature> Features>
: Processor<Name, GenericItineraries, 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.
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<"arm7tdmi", [ArchV4T]>;
def : ProcNoItin<"arm7tdmi-s", [ArchV4T]>;
def : ProcNoItin<"arm710t", [ArchV4T]>;
def : ProcNoItin<"arm720t", [ArchV4T]>;
def : ProcNoItin<"arm9", [ArchV4T]>;
def : ProcNoItin<"arm9tdmi", [ArchV4T]>;
def : ProcNoItin<"arm920", [ArchV4T]>;
def : ProcNoItin<"arm920t", [ArchV4T]>;
def : ProcNoItin<"arm922t", [ArchV4T]>;
def : ProcNoItin<"arm940t", [ArchV4T]>;
def : ProcNoItin<"ep9312", [ArchV4T]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
// V5T 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<"arm10tdmi", [ArchV5T]>;
def : ProcNoItin<"arm1020t", [ArchV5T]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
// V5TE 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<"arm9e", [ArchV5TE]>;
def : ProcNoItin<"arm926ej-s", [ArchV5TE]>;
def : ProcNoItin<"arm946e-s", [ArchV5TE]>;
def : ProcNoItin<"arm966e-s", [ArchV5TE]>;
def : ProcNoItin<"arm968e-s", [ArchV5TE]>;
def : ProcNoItin<"arm10e", [ArchV5TE]>;
def : ProcNoItin<"arm1020e", [ArchV5TE]>;
def : ProcNoItin<"arm1022e", [ArchV5TE]>;
def : ProcNoItin<"xscale", [ArchV5TE]>;
def : ProcNoItin<"iwmmxt", [ArchV5TE]>;
ARM backend contribution from Apple. llvm-svn: 33353
2007-01-19 15:51:42 +08:00
// V6 Processors.
Add ARMv6 itineraries. llvm-svn: 89218
2009-11-19 02:39:57 +08:00
def : Processor<"arm1136j-s", ARMV6Itineraries, [ArchV6]>;
vml[as] are slow on 1136jf-s also. llvm-svn: 100066
2010-04-01 08:13:43 +08:00
def : Processor<"arm1136jf-s", ARMV6Itineraries, [ArchV6, 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]>;
Add ARMv6 itineraries. llvm-svn: 89218
2009-11-19 02:39:57 +08:00
def : Processor<"arm1176jz-s", ARMV6Itineraries, [ArchV6]>;
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 : Processor<"arm1176jzf-s", ARMV6Itineraries, [ArchV6, FeatureVFP2,
FeatureHasSlowFPVMLx]>;
Add ARMv6 itineraries. llvm-svn: 89218
2009-11-19 02:39:57 +08:00
def : Processor<"mpcorenovfp", ARMV6Itineraries, [ArchV6]>;
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 : Processor<"mpcore", ARMV6Itineraries, [ArchV6, FeatureVFP2,
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.
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) llvm-svn: 110795
2010-08-11 14:51:54 +08:00
def : Processor<"cortex-m0", ARMV6Itineraries, [ArchV6M]>;
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.
ArchV6T2, V7A, and V7M implies Thumb2; Archv7A implies NEON. llvm-svn: 110796
2010-08-11 14:57:53 +08:00
def : Processor<"arm1156t2-s", ARMV6Itineraries, [ArchV6T2]>;
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 : Processor<"arm1156t2f-s", ARMV6Itineraries, [ArchV6T2, FeatureVFP2,
FeatureHasSlowFPVMLx]>;
Add placeholder for thumb2 stuff llvm-svn: 72593
2009-05-30 07:41:08 +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
// V7 Processors.
Add fake v7 itineraries for now. llvm-svn: 76612
2009-07-22 02:54:14 +08:00
def : Processor<"cortex-a8", CortexA8Itineraries,
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
[ArchV7A, ProcA8,
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, FeatureT2XtPk]>;
Some bits of A9 scheduling: VFP llvm-svn: 100643
2010-04-08 02:19:18 +08:00
def : Processor<"cortex-a9", CortexA9Itineraries,
Add some missing isel predicates on def : pat patterns to avoid generating VFP vmla / vmls (they cause stalls). Disabling them in isel is properly not a right solution, I'll look into a proper solution next. llvm-svn: 118922
2010-11-13 04:32:20 +08:00
[ArchV7A, ProcA9,
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, FeatureT2XtPk]>;
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.
ArchV7M implies HW division instructions. llvm-svn: 110797
2010-08-11 15:00:16 +08:00
def : ProcNoItin<"cortex-m3", [ArchV7M]>;
cortex m4 has floating point support, but only single precision. llvm-svn: 110810
2010-08-11 23:44:15 +08:00
def : ProcNoItin<"cortex-m4", [ArchV7M, FeatureVFP2, FeatureVFPOnlySP]>;
Add ARMv7 architecture, Cortex processors and different FPU modes handling. llvm-svn: 72337
2009-05-24 03:51:43 +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
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
//===----------------------------------------------------------------------===//
// Assembly printer
//===----------------------------------------------------------------------===//
// ARM Uses the MC printer for asm output, so make sure the TableGen
// AsmWriter bits get associated with the correct class.
def ARMAsmWriter : AsmWriter {
string AsmWriterClassName = "InstPrinter";
bit isMCAsmWriter = 1;
}
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;
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
let AssemblyWriters = [ARMAsmWriter];
added a skeleton of the ARM backend llvm-svn: 28301
2006-05-15 06:18:28 +08:00
}