6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-21 00:32:23 +00:00
Code Issues Projects Releases Wiki Activity
5eda282cd1
llvm-6502/lib/Target/ARM/ARM.td

216 lines
9.7 KiB
TableGen
Raw Normal View History

fix emacs language spec's, patch by Edmund Grimley-Evans! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111241 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-17 16:20:04 +00:00
//===- ARM.td - Describe the ARM Target Machine ------------*- tablegen -*-===//
added a skeleton of the ARM backend git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28301 91177308-0d34-0410-b5e6-96231b3b80d8
2006-05-14 22:18:28 +00:00
//
// The LLVM Compiler Infrastructure
//
Remove attribution from file headers, per discussion on llvmdev. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45418 91177308-0d34-0410-b5e6-96231b3b80d8
2007-12-29 20:36:04 +00:00
// This file is distributed under the University of Illinois Open Source
added a skeleton of the ARM backend git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28301 91177308-0d34-0410-b5e6-96231b3b80d8
2006-05-14 22:18:28 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59953 91177308-0d34-0410-b5e6-96231b3b80d8
2008-11-24 07:34:46 +00:00
include "llvm/Target/Target.td"
added a skeleton of the ARM backend git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28301 91177308-0d34-0410-b5e6-96231b3b80d8
2006-05-14 22:18:28 +00:00
Nuke it from orbit. It's the only way to be sure. (Kill the dead non-MC asm printer for the ARM target.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115127 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 01:57:53 +00:00
ARM backend contribution from Apple. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33353 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-19 07:51:42 +00:00
//===----------------------------------------------------------------------===//
// ARM Subtarget features.
//
Add ARMv7 architecture, Cortex processors and different FPU modes handling. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72337 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-23 19:51:43 +00:00
def FeatureVFP2 : SubtargetFeature<"vfp2", "ARMFPUType", "VFPv2",
Add placeholder for thumb2 stuff git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72593 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-29 23:41:08 +00:00
"Enable VFP2 instructions">;
Add ARMv7 architecture, Cortex processors and different FPU modes handling. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72337 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-23 19:51:43 +00:00
def FeatureVFP3 : SubtargetFeature<"vfp3", "ARMFPUType", "VFPv3",
Add placeholder for thumb2 stuff git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72593 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-29 23:41:08 +00:00
"Enable VFP3 instructions">;
Add ARMv7 architecture, Cortex processors and different FPU modes handling. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72337 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-23 19:51:43 +00:00
def FeatureNEON : SubtargetFeature<"neon", "ARMFPUType", "NEON",
Add placeholder for thumb2 stuff git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72593 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-29 23:41:08 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110798 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 07:17:46 +00:00
def FeatureNoARM : SubtargetFeature<"noarm", "NoARM", "true",
"Does not support ARM mode execution">;
Add substarget feature for FP16 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98503 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-14 18:42:38 +00: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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116310 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-12 16:22:47 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103136 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-05 23:44:43 +00:00
def FeatureHWDiv : SubtargetFeature<"hwdiv", "HasHardwareDivide", "true",
"Enable divide instructions">;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110795 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:51:54 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103136 91177308-0d34-0410-b5e6-96231b3b80d8
2010-05-05 23:44:43 +00:00
"Enable Thumb2 extract and pack instructions">;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110795 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:51:54 +00: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). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108256 91177308-0d34-0410-b5e6-96231b3b80d8
2010-07-13 19:21:50 +00:00
def FeatureSlowFPBrcc : SubtargetFeature<"slow-fp-brcc", "SlowFPBrcc", "true",
"FP compare + branch is slow">;
cortex m4 has floating point support, but only single precision. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110810 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 15:44:15 +00:00
def FeatureVFPOnlySP : SubtargetFeature<"fp-only-sp", "FPOnlySP", "true",
"Floating point unit supports single precision only">;
ARM backend contribution from Apple. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33353 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-19 07:51:42 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120960 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-05 22:04:16 +00: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' git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99565 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-25 23:11:16 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120960 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-05 22:04:16 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99570 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-25 23:47:34 +00:00
// Some processors benefit from using NEON instructions for scalar
// single-precision FP operations.
80 column cleanup. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@111266 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-17 18:39:16 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99570 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-25 23:47:34 +00:00
Change -prefer-32bit-thumb to attribute -mattr=+32bit instead to disable more 32-bit to 16-bit optimizations. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110584 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-09 18:35:19 +00: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' git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@99565 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-25 23:11:16 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@118160 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-03 06:34:55 +00:00
// Multiprocessing extension.
def FeatureMP : SubtargetFeature<"mp", "HasMPExtension", "true",
"Supports Multiprocessing extension">;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110795 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:51:54 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110798 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 07:17:46 +00:00
[FeatureNoARM, FeatureDB]>;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110795 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:51:54 +00:00
def ArchV6T2 : SubtargetFeature<"v6t2", "ARMArchVersion", "V6T2",
ArchV6T2, V7A, and V7M implies Thumb2; Archv7A implies NEON. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110796 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:57:53 +00:00
"ARM v6t2",
[FeatureThumb2]>;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110795 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:51:54 +00:00
def ArchV7A : SubtargetFeature<"v7a", "ARMArchVersion", "V7A",
"ARM v7A",
ArchV6T2, V7A, and V7M implies Thumb2; Archv7A implies NEON. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110796 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:57:53 +00:00
[FeatureThumb2, FeatureNEON, FeatureDB]>;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110795 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:51:54 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110798 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 07:17:46 +00:00
[FeatureThumb2, FeatureNoARM, FeatureDB,
FeatureHWDiv]>;
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110795 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:51:54 +00:00
ARM backend contribution from Apple. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33353 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-19 07:51:42 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73747 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-19 01:51:50 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113570 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-10 01:29:16 +00: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",
Code clean up. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120965 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-05 23:03:45 +00:00
[FeatureSlowFPBrcc, FeatureNEONForFP,
FeatureHasSlowFPVMLx, 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113570 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-10 01:29:16 +00:00
def ProcA9 : SubtargetFeature<"a9", "ARMProcFamily", "CortexA9",
Code clean up. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120965 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-05 23:03:45 +00:00
"Cortex-A9 ARM processors",
Add Neon VCVT instructions for f32 <-> f16 conversions. Clang is now providing intrinsics for these and so we need to support them in the backend. Radar 8068427. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121902 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-15 22:14:12 +00:00
[FeatureHasSlowFPVMLx, FeatureT2XtPk,
FeatureFP16]>;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113570 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-10 01:29:16 +00:00
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73747 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-19 01:51:50 +00:00
class ProcNoItin<string Name, list<SubtargetFeature> Features>
: Processor<Name, GenericItineraries, Features>;
ARM backend contribution from Apple. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33353 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-19 07:51:42 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73747 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-19 01:51:50 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33353 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-19 07:51:42 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73747 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-19 01:51:50 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33353 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-19 07:51:42 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73747 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-19 01:51:50 +00:00
def : ProcNoItin<"arm10tdmi", [ArchV5T]>;
def : ProcNoItin<"arm1020t", [ArchV5T]>;
ARM backend contribution from Apple. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33353 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-19 07:51:42 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73747 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-19 01:51:50 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33353 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-19 07:51:42 +00:00
// V6 Processors.
Add ARMv6 itineraries. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89218 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-18 18:39:57 +00:00
def : Processor<"arm1136j-s", ARMV6Itineraries, [ArchV6]>;
vml[as] are slow on 1136jf-s also. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100066 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-01 00:13:43 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120960 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-05 22:04:16 +00:00
FeatureHasSlowFPVMLx]>;
Add ARMv6 itineraries. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89218 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-18 18:39:57 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120960 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-05 22:04:16 +00:00
def : Processor<"arm1176jzf-s", ARMV6Itineraries, [ArchV6, FeatureVFP2,
FeatureHasSlowFPVMLx]>;
Add ARMv6 itineraries. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89218 91177308-0d34-0410-b5e6-96231b3b80d8
2009-11-18 18:39:57 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120960 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-05 22:04:16 +00:00
def : Processor<"mpcore", ARMV6Itineraries, [ArchV6, FeatureVFP2,
FeatureHasSlowFPVMLx]>;
ARM backend contribution from Apple. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33353 91177308-0d34-0410-b5e6-96231b3b80d8
2007-01-19 07:51:42 +00:00
Add Cortex-M0 support. It's a ARMv6m device (no ARM mode) with some 32-bit instructions: dmb, dsb, isb, msr, and mrs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110786 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:30:38 +00:00
// V6M Processors.
Add ARM Archv6M and let it implies FeatureDB (having dmb, etc.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110795 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:51:54 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110786 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:30:38 +00:00
Separate V6 from V6T2 since the latter has some extra nice instructions git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73085 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-08 21:20:36 +00:00
// V6T2 Processors.
ArchV6T2, V7A, and V7M implies Thumb2; Archv7A implies NEON. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110796 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:57:53 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120960 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-05 22:04:16 +00:00
def : Processor<"arm1156t2f-s", ARMV6Itineraries, [ArchV6T2, FeatureVFP2,
FeatureHasSlowFPVMLx]>;
Add placeholder for thumb2 stuff git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72593 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-29 23:41:08 +00:00
Separate V6 from V6T2 since the latter has some extra nice instructions git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@73085 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-08 21:20:36 +00:00
// V7 Processors.
Add fake v7 itineraries for now. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-07-21 18:54:14 +00:00
def : Processor<"cortex-a8", CortexA8Itineraries,
Code clean up. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120965 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-05 23:03:45 +00:00
[ArchV7A, ProcA8]>;
Some bits of A9 scheduling: VFP git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100643 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-07 18:19:18 +00:00
def : Processor<"cortex-a9", CortexA9Itineraries,
Code clean up. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120965 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-05 23:03:45 +00:00
[ArchV7A, ProcA9]>;
Add Cortex-M0 support. It's a ARMv6m device (no ARM mode) with some 32-bit instructions: dmb, dsb, isb, msr, and mrs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110786 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 06:30:38 +00:00
// V7M Processors.
ArchV7M implies HW division instructions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110797 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 07:00:16 +00:00
def : ProcNoItin<"cortex-m3", [ArchV7M]>;
cortex m4 has floating point support, but only single precision. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@110810 91177308-0d34-0410-b5e6-96231b3b80d8
2010-08-11 15:44:15 +00:00
def : ProcNoItin<"cortex-m4", [ArchV7M, FeatureVFP2, FeatureVFPOnlySP]>;
Add ARMv7 architecture, Cortex processors and different FPU modes handling. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72337 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-23 19:51:43 +00:00
added a skeleton of the ARM backend git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28301 91177308-0d34-0410-b5e6-96231b3b80d8
2006-05-14 22:18:28 +00:00
//===----------------------------------------------------------------------===//
// Register File Description
//===----------------------------------------------------------------------===//
include "ARMRegisterInfo.td"
Use CallConvLower.h and TableGen descriptions of the calling conventions for ARM. Patch by Sandeep Patel. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69371 91177308-0d34-0410-b5e6-96231b3b80d8
2009-04-17 19:07:39 +00:00
include "ARMCallingConv.td"
added a skeleton of the ARM backend git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28301 91177308-0d34-0410-b5e6-96231b3b80d8
2006-05-14 22:18:28 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100384 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-05 03:10:20 +00:00
def ARMInstrInfo : InstrInfo;
added a skeleton of the ARM backend git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28301 91177308-0d34-0410-b5e6-96231b3b80d8
2006-05-14 22:18:28 +00:00
Nuke it from orbit. It's the only way to be sure. (Kill the dead non-MC asm printer for the ARM target.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115127 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 01:57:53 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28301 91177308-0d34-0410-b5e6-96231b3b80d8
2006-05-14 22:18:28 +00: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.) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115127 91177308-0d34-0410-b5e6-96231b3b80d8
2010-09-30 01:57:53 +00:00
let AssemblyWriters = [ARMAsmWriter];
added a skeleton of the ARM backend git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@28301 91177308-0d34-0410-b5e6-96231b3b80d8
2006-05-14 22:18:28 +00:00
}
Reference in New Issue Copy Permalink