2012-02-18 20:03:15 +08:00
|
|
|
//===-- ARM.td - Describe the ARM Target Machine -----------*- tablegen -*-===//
|
2006-05-15 06:18:28 +08:00
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2006-05-15 06:18:28 +08:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
//
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// Target-independent interfaces which we are implementing
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2008-11-24 15:34:46 +08:00
|
|
|
include "llvm/Target/Target.td"
|
2006-05-15 06:18:28 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2017-07-13 18:24:30 +08:00
|
|
|
// ARM Subtarget state.
|
2015-11-16 19:10:19 +08:00
|
|
|
//
|
|
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
def ModeThumb : SubtargetFeature<"thumb-mode", "InThumbMode",
|
|
|
|
|
"true", "Thumb mode">;
|
|
|
|
|
|
|
|
|
|
def ModeSoftFloat : SubtargetFeature<"soft-float","UseSoftFloat",
|
|
|
|
|
"true", "Use software floating "
|
|
|
|
|
"point features.">;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
|
|
|
|
|
2011-07-07 16:26:46 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2017-07-13 18:24:30 +08:00
|
|
|
// ARM Subtarget features.
|
2011-07-07 16:26:46 +08:00
|
|
|
//
|
|
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
// Floating Point, HW Division and Neon Support
|
2019-05-30 20:37:05 +08:00
|
|
|
|
|
|
|
|
// FP loads/stores/moves, shared between VFP and MVE (even in the integer-only
|
|
|
|
|
// version).
|
|
|
|
|
def FeatureFPRegs : SubtargetFeature<"fpregs", "HasFPRegs", "true",
|
|
|
|
|
"Enable FP registers">;
|
|
|
|
|
|
|
|
|
|
// 16-bit FP loads/stores/moves, shared between VFP (with the v8.2A FP16
|
|
|
|
|
// extension) and MVE (even in the integer-only version).
|
|
|
|
|
def FeatureFPRegs16 : SubtargetFeature<"fpregs16", "HasFPRegs16", "true",
|
|
|
|
|
"Enable 16-bit FP registers",
|
|
|
|
|
[FeatureFPRegs]>;
|
|
|
|
|
|
|
|
|
|
def FeatureFPRegs64 : SubtargetFeature<"fpregs64", "HasFPRegs64", "true",
|
|
|
|
|
"Enable 64-bit FP registers",
|
|
|
|
|
[FeatureFPRegs]>;
|
|
|
|
|
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
def FeatureFP64 : SubtargetFeature<"fp64", "HasFP64", "true",
|
|
|
|
|
"Floating point unit supports "
|
2019-05-30 20:37:05 +08:00
|
|
|
"double precision",
|
|
|
|
|
[FeatureFPRegs64]>;
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
|
|
|
|
|
def FeatureD32 : SubtargetFeature<"d32", "HasD32", "true",
|
|
|
|
|
"Extend FP to 32 double registers">;
|
|
|
|
|
|
|
|
|
|
multiclass VFPver<string name, string query, string description,
|
2019-09-18 05:42:38 +08:00
|
|
|
list<SubtargetFeature> prev,
|
|
|
|
|
list<SubtargetFeature> otherimplies,
|
|
|
|
|
list<SubtargetFeature> vfp2prev = []> {
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
def _D16_SP: SubtargetFeature<
|
|
|
|
|
name#"d16sp", query#"D16SP", "true",
|
|
|
|
|
description#" with only 16 d-registers and no double precision",
|
2019-09-18 05:42:38 +08:00
|
|
|
!foreach(v, prev, !cast<SubtargetFeature>(v # "_D16_SP")) #
|
|
|
|
|
!foreach(v, vfp2prev, !cast<SubtargetFeature>(v # "_SP")) #
|
|
|
|
|
otherimplies>;
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
def _SP: SubtargetFeature<
|
|
|
|
|
name#"sp", query#"SP", "true",
|
|
|
|
|
description#" with no double precision",
|
|
|
|
|
!foreach(v, prev, !cast<SubtargetFeature>(v # "_SP")) #
|
|
|
|
|
otherimplies # [FeatureD32, !cast<SubtargetFeature>(NAME # "_D16_SP")]>;
|
|
|
|
|
def _D16: SubtargetFeature<
|
|
|
|
|
name#"d16", query#"D16", "true",
|
|
|
|
|
description#" with only 16 d-registers",
|
|
|
|
|
!foreach(v, prev, !cast<SubtargetFeature>(v # "_D16")) #
|
2019-09-18 05:42:38 +08:00
|
|
|
vfp2prev #
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
otherimplies # [FeatureFP64, !cast<SubtargetFeature>(NAME # "_D16_SP")]>;
|
|
|
|
|
def "": SubtargetFeature<
|
|
|
|
|
name, query, "true", description,
|
|
|
|
|
prev # otherimplies # [
|
|
|
|
|
!cast<SubtargetFeature>(NAME # "_D16"),
|
|
|
|
|
!cast<SubtargetFeature>(NAME # "_SP")]>;
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-18 05:42:38 +08:00
|
|
|
def FeatureVFP2_SP : SubtargetFeature<"vfp2sp", "HasVFPv2SP", "true",
|
|
|
|
|
"Enable VFP2 instructions with "
|
|
|
|
|
"no double precision",
|
|
|
|
|
[FeatureFPRegs]>;
|
|
|
|
|
|
|
|
|
|
def FeatureVFP2 : SubtargetFeature<"vfp2", "HasVFPv2", "true",
|
|
|
|
|
"Enable VFP2 instructions",
|
|
|
|
|
[FeatureFP64, FeatureVFP2_SP]>;
|
2019-05-30 20:37:05 +08:00
|
|
|
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
defm FeatureVFP3: VFPver<"vfp3", "HasVFPv3", "Enable VFP3 instructions",
|
2019-09-18 05:42:38 +08:00
|
|
|
[], [], [FeatureVFP2]>;
|
2015-05-12 09:26:05 +08:00
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureNEON : SubtargetFeature<"neon", "HasNEON", "true",
|
|
|
|
|
"Enable NEON instructions",
|
|
|
|
|
[FeatureVFP3]>;
|
|
|
|
|
|
|
|
|
|
def FeatureFP16 : SubtargetFeature<"fp16", "HasFP16", "true",
|
|
|
|
|
"Enable half-precision "
|
|
|
|
|
"floating point">;
|
|
|
|
|
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
defm FeatureVFP4: VFPver<"vfp4", "HasVFPv4", "Enable VFP4 instructions",
|
|
|
|
|
[FeatureVFP3], [FeatureFP16]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
defm FeatureFPARMv8: VFPver<"fp-armv8", "HasFPARMv8", "Enable ARMv8 FP",
|
2019-09-18 05:42:38 +08:00
|
|
|
[FeatureVFP4], []>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
|
|
|
|
def FeatureFullFP16 : SubtargetFeature<"fullfp16", "HasFullFP16", "true",
|
|
|
|
|
"Enable full half-precision "
|
|
|
|
|
"floating point",
|
2019-05-30 20:37:05 +08:00
|
|
|
[FeatureFPARMv8_D16_SP, FeatureFPRegs16]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2018-08-17 19:29:49 +08:00
|
|
|
def FeatureFP16FML : SubtargetFeature<"fp16fml", "HasFP16FML", "true",
|
|
|
|
|
"Enable full half-precision "
|
|
|
|
|
"floating point fml instructions",
|
|
|
|
|
[FeatureFullFP16]>;
|
|
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureHWDivThumb : SubtargetFeature<"hwdiv",
|
|
|
|
|
"HasHardwareDivideInThumb", "true",
|
|
|
|
|
"Enable divide instructions in Thumb">;
|
|
|
|
|
|
|
|
|
|
def FeatureHWDivARM : SubtargetFeature<"hwdiv-arm",
|
|
|
|
|
"HasHardwareDivideInARM", "true",
|
|
|
|
|
"Enable divide instructions in ARM mode">;
|
|
|
|
|
|
|
|
|
|
// Atomic Support
|
|
|
|
|
def FeatureDB : SubtargetFeature<"db", "HasDataBarrier", "true",
|
|
|
|
|
"Has data barrier (dmb/dsb) instructions">;
|
|
|
|
|
|
|
|
|
|
def FeatureV7Clrex : SubtargetFeature<"v7clrex", "HasV7Clrex", "true",
|
|
|
|
|
"Has v7 clrex instruction">;
|
2007-01-19 15:51:42 +08:00
|
|
|
|
2017-12-21 19:17:49 +08:00
|
|
|
def FeatureDFB : SubtargetFeature<"dfb", "HasFullDataBarrier", "true",
|
|
|
|
|
"Has full data barrier (dfb) instruction">;
|
|
|
|
|
|
2016-01-15 18:23:46 +08:00
|
|
|
def FeatureAcquireRelease : SubtargetFeature<"acquire-release",
|
|
|
|
|
"HasAcquireRelease", "true",
|
2017-07-13 18:24:30 +08:00
|
|
|
"Has v8 acquire/release (lda/ldaex "
|
|
|
|
|
" etc) instructions">;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
def FeatureSlowFPBrcc : SubtargetFeature<"slow-fp-brcc", "SlowFPBrcc", "true",
|
|
|
|
|
"FP compare + branch is slow">;
|
|
|
|
|
|
|
|
|
|
def FeaturePerfMon : SubtargetFeature<"perfmon", "HasPerfMon", "true",
|
|
|
|
|
"Enable support for Performance "
|
|
|
|
|
"Monitor extensions">;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
// TrustZone Security Extensions
|
|
|
|
|
def FeatureTrustZone : SubtargetFeature<"trustzone", "HasTrustZone", "true",
|
|
|
|
|
"Enable support for TrustZone "
|
|
|
|
|
"security extensions">;
|
|
|
|
|
|
|
|
|
|
def Feature8MSecExt : SubtargetFeature<"8msecext", "Has8MSecExt", "true",
|
|
|
|
|
"Enable support for ARMv8-M "
|
|
|
|
|
"Security Extensions">;
|
|
|
|
|
|
[ARM][AArch64] Armv8.4-A Enablement
Initial patch adding assembly support for Armv8.4-A.
Besides adding v8.4 as a supported architecture to the usual places, this also
adds target features for the different crypto algorithms. Armv8.4-A introduced
new crypto algorithms, made them optional, and allows different combinations:
- none of the v8.4 crypto functions are supported, which is independent of the
implementation of the Armv8.0 SHA1 and SHA2 instructions.
- the v8.4 SHA512 and SHA3 support is implemented, in this case the Armv8.0
SHA1 and SHA2 instructions must also be implemented.
- the v8.4 SM3 and SM4 support is implemented, which is independent of the
implementation of the Armv8.0 SHA1 and SHA2 instructions.
- all of the v8.4 crypto functions are supported, in this case the Armv8.0 SHA1
and SHA2 instructions must also be implemented.
The v8.4 crypto instructions are added to AArch64 only, and not AArch32,
and are made optional extensions to Armv8.2-A.
The user-facing Clang options will map on these new target features, their
naming will be compatible with GCC and added in follow-up patches.
The Armv8.4-A instruction sets can be downloaded here:
https://developer.arm.com/products/architecture/a-profile/exploration-tools
Differential Revision: https://reviews.llvm.org/D48625
llvm-svn: 335953
2018-06-29 16:43:19 +08:00
|
|
|
def FeatureSHA2 : SubtargetFeature<"sha2", "HasSHA2", "true",
|
|
|
|
|
"Enable SHA1 and SHA256 support", [FeatureNEON]>;
|
|
|
|
|
|
|
|
|
|
def FeatureAES : SubtargetFeature<"aes", "HasAES", "true",
|
|
|
|
|
"Enable AES support", [FeatureNEON]>;
|
|
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureCrypto : SubtargetFeature<"crypto", "HasCrypto", "true",
|
|
|
|
|
"Enable support for "
|
|
|
|
|
"Cryptography extensions",
|
[ARM][AArch64] Armv8.4-A Enablement
Initial patch adding assembly support for Armv8.4-A.
Besides adding v8.4 as a supported architecture to the usual places, this also
adds target features for the different crypto algorithms. Armv8.4-A introduced
new crypto algorithms, made them optional, and allows different combinations:
- none of the v8.4 crypto functions are supported, which is independent of the
implementation of the Armv8.0 SHA1 and SHA2 instructions.
- the v8.4 SHA512 and SHA3 support is implemented, in this case the Armv8.0
SHA1 and SHA2 instructions must also be implemented.
- the v8.4 SM3 and SM4 support is implemented, which is independent of the
implementation of the Armv8.0 SHA1 and SHA2 instructions.
- all of the v8.4 crypto functions are supported, in this case the Armv8.0 SHA1
and SHA2 instructions must also be implemented.
The v8.4 crypto instructions are added to AArch64 only, and not AArch32,
and are made optional extensions to Armv8.2-A.
The user-facing Clang options will map on these new target features, their
naming will be compatible with GCC and added in follow-up patches.
The Armv8.4-A instruction sets can be downloaded here:
https://developer.arm.com/products/architecture/a-profile/exploration-tools
Differential Revision: https://reviews.llvm.org/D48625
llvm-svn: 335953
2018-06-29 16:43:19 +08:00
|
|
|
[FeatureNEON, FeatureSHA2, FeatureAES]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
|
|
|
|
def FeatureCRC : SubtargetFeature<"crc", "HasCRC", "true",
|
|
|
|
|
"Enable support for CRC instructions">;
|
|
|
|
|
|
2017-08-11 17:52:30 +08:00
|
|
|
def FeatureDotProd : SubtargetFeature<"dotprod", "HasDotProd", "true",
|
|
|
|
|
"Enable support for dot product instructions",
|
|
|
|
|
[FeatureNEON]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2016-06-03 22:03:27 +08:00
|
|
|
// Not to be confused with FeatureHasRetAddrStack (return address stack)
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureRAS : SubtargetFeature<"ras", "HasRAS", "true",
|
|
|
|
|
"Enable Reliability, Availability "
|
|
|
|
|
"and Serviceability extensions">;
|
|
|
|
|
|
|
|
|
|
// Fast computation of non-negative address offsets
|
|
|
|
|
def FeatureFPAO : SubtargetFeature<"fpao", "HasFPAO", "true",
|
|
|
|
|
"Enable fast computation of "
|
|
|
|
|
"positive address offsets">;
|
|
|
|
|
|
|
|
|
|
// Fast execution of AES crypto operations
|
|
|
|
|
def FeatureFuseAES : SubtargetFeature<"fuse-aes", "HasFuseAES", "true",
|
|
|
|
|
"CPU fuses AES crypto operations">;
|
|
|
|
|
|
2018-07-28 02:16:47 +08:00
|
|
|
// Fast execution of bottom and top halves of literal generation
|
|
|
|
|
def FeatureFuseLiterals : SubtargetFeature<"fuse-literals", "HasFuseLiterals", "true",
|
|
|
|
|
"CPU fuses literal generation operations">;
|
|
|
|
|
|
2017-07-28 20:54:57 +08:00
|
|
|
// The way of reading thread pointer
|
|
|
|
|
def FeatureReadTp : SubtargetFeature<"read-tp-hard", "ReadTPHard", "true",
|
|
|
|
|
"Reading thread pointer from register">;
|
|
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
// Cyclone can zero VFP registers in 0 cycles.
|
|
|
|
|
def FeatureZCZeroing : SubtargetFeature<"zcz", "HasZeroCycleZeroing", "true",
|
|
|
|
|
"Has zero-cycle zeroing instructions">;
|
|
|
|
|
|
|
|
|
|
// Whether it is profitable to unpredicate certain instructions during if-conversion
|
2016-06-23 15:47:35 +08:00
|
|
|
def FeatureProfUnpredicate : SubtargetFeature<"prof-unpr",
|
2017-07-13 18:24:30 +08:00
|
|
|
"IsProfitableToUnpredicate", "true",
|
2016-06-23 15:47:35 +08:00
|
|
|
"Is profitable to unpredicate">;
|
|
|
|
|
|
|
|
|
|
// Some targets (e.g. Swift) have microcoded VGETLNi32.
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureSlowVGETLNi32 : SubtargetFeature<"slow-vgetlni32",
|
|
|
|
|
"HasSlowVGETLNi32", "true",
|
|
|
|
|
"Has slow VGETLNi32 - prefer VMOV">;
|
2016-06-23 15:47:35 +08:00
|
|
|
|
|
|
|
|
// Some targets (e.g. Swift) have microcoded VDUP32.
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureSlowVDUP32 : SubtargetFeature<"slow-vdup32", "HasSlowVDUP32",
|
|
|
|
|
"true",
|
|
|
|
|
"Has slow VDUP32 - prefer VMOV">;
|
2016-06-23 15:47:35 +08:00
|
|
|
|
|
|
|
|
// Some targets (e.g. Cortex-A9) prefer VMOVSR to VMOVDRR even when using NEON
|
|
|
|
|
// for scalar FP, as this allows more effective execution domain optimization.
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeaturePreferVMOVSR : SubtargetFeature<"prefer-vmovsr", "PreferVMOVSR",
|
|
|
|
|
"true", "Prefer VMOVSR">;
|
2016-06-23 15:47:35 +08:00
|
|
|
|
|
|
|
|
// Swift has ISHST barriers compatible with Atomic Release semantics but weaker
|
|
|
|
|
// than ISH
|
|
|
|
|
def FeaturePrefISHSTBarrier : SubtargetFeature<"prefer-ishst", "PreferISHST",
|
2017-07-13 18:24:30 +08:00
|
|
|
"true", "Prefer ISHST barriers">;
|
2016-06-23 15:47:35 +08:00
|
|
|
|
2016-07-06 17:22:23 +08:00
|
|
|
// Some targets (e.g. Cortex-A9) have muxed AGU and NEON/FPU.
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureMuxedUnits : SubtargetFeature<"muxed-units", "HasMuxedUnits",
|
|
|
|
|
"true",
|
|
|
|
|
"Has muxed AGU and NEON/FPU">;
|
2016-07-06 17:22:23 +08:00
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
// Whether VLDM/VSTM starting with odd register number need more microops
|
|
|
|
|
// than single VLDRS
|
2016-07-06 17:22:23 +08:00
|
|
|
def FeatureSlowOddRegister : SubtargetFeature<"slow-odd-reg", "SlowOddRegister",
|
2017-07-13 18:24:30 +08:00
|
|
|
"true", "VLDM/VSTM starting "
|
|
|
|
|
"with an odd register is slow">;
|
2016-07-06 17:22:23 +08:00
|
|
|
|
|
|
|
|
// Some targets have a renaming dependency when loading into D subregisters.
|
|
|
|
|
def FeatureSlowLoadDSubreg : SubtargetFeature<"slow-load-D-subreg",
|
|
|
|
|
"SlowLoadDSubregister", "true",
|
|
|
|
|
"Loading into D subregs is slow">;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2018-08-10 00:13:24 +08:00
|
|
|
def FeatureUseWideStrideVFP : SubtargetFeature<"wide-stride-vfp",
|
|
|
|
|
"UseWideStrideVFP", "true",
|
|
|
|
|
"Use a wide stride when allocating VFP registers">;
|
|
|
|
|
|
2016-07-06 19:22:11 +08:00
|
|
|
// Some targets (e.g. Cortex-A15) never want VMOVS to be widened to VMOVD.
|
|
|
|
|
def FeatureDontWidenVMOVS : SubtargetFeature<"dont-widen-vmovs",
|
|
|
|
|
"DontWidenVMOVS", "true",
|
|
|
|
|
"Don't widen VMOVS to VMOVD">;
|
2016-07-06 17:22:23 +08:00
|
|
|
|
2018-07-21 00:49:28 +08:00
|
|
|
// Some targets (e.g. Cortex-A15) prefer to avoid mixing operations on different
|
|
|
|
|
// VFP register widths.
|
|
|
|
|
def FeatureSplatVFPToNeon : SubtargetFeature<"splat-vfp-neon",
|
|
|
|
|
"SplatVFPToNeon", "true",
|
|
|
|
|
"Splat register from VFP to NEON",
|
|
|
|
|
[FeatureDontWidenVMOVS]>;
|
|
|
|
|
|
2016-07-07 17:11:39 +08:00
|
|
|
// Whether or not it is profitable to expand VFP/NEON MLA/MLS instructions.
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureExpandMLx : SubtargetFeature<"expand-fp-mlx",
|
|
|
|
|
"ExpandMLx", "true",
|
|
|
|
|
"Expand VFP/NEON MLA/MLS instructions">;
|
2016-07-07 17:11:39 +08:00
|
|
|
|
|
|
|
|
// Some targets have special RAW hazards for VFP/NEON VMLA/VMLS.
|
|
|
|
|
def FeatureHasVMLxHazards : SubtargetFeature<"vmlx-hazards", "HasVMLxHazards",
|
|
|
|
|
"true", "Has VMLx hazards">;
|
|
|
|
|
|
2016-06-23 15:47:35 +08:00
|
|
|
// Some targets (e.g. Cortex-A9) want to convert VMOVRS, VMOVSR and VMOVS from
|
|
|
|
|
// VFP to NEON, as an execution domain optimization.
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureNEONForFPMovs : SubtargetFeature<"neon-fpmovs",
|
|
|
|
|
"UseNEONForFPMovs", "true",
|
|
|
|
|
"Convert VMOVSR, VMOVRS, "
|
|
|
|
|
"VMOVS to NEON">;
|
2016-06-23 15:47:35 +08:00
|
|
|
|
|
|
|
|
// Some processors benefit from using NEON instructions for scalar
|
|
|
|
|
// single-precision FP operations. This affects instruction selection and should
|
|
|
|
|
// only be enabled if the handling of denormals is not important.
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureNEONForFP : SubtargetFeature<"neonfp",
|
|
|
|
|
"UseNEONForSinglePrecisionFP",
|
|
|
|
|
"true",
|
|
|
|
|
"Use NEON for single precision FP">;
|
2016-06-23 15:47:35 +08:00
|
|
|
|
2016-06-27 17:08:23 +08:00
|
|
|
// On some processors, VLDn instructions that access unaligned data take one
|
|
|
|
|
// extra cycle. Take that into account when computing operand latencies.
|
|
|
|
|
def FeatureCheckVLDnAlign : SubtargetFeature<"vldn-align", "CheckVLDnAlign",
|
|
|
|
|
"true",
|
|
|
|
|
"Check for VLDn unaligned access">;
|
|
|
|
|
|
|
|
|
|
// Some processors have a nonpipelined VFP coprocessor.
|
|
|
|
|
def FeatureNonpipelinedVFP : SubtargetFeature<"nonpipelined-vfp",
|
|
|
|
|
"NonpipelinedVFP", "true",
|
2017-07-13 18:24:30 +08:00
|
|
|
"VFP instructions are not pipelined">;
|
2016-06-27 17:08:23 +08:00
|
|
|
|
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
|
2010-03-26 07:11:16 +08:00
|
|
|
// to just not use them.
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureHasSlowFPVMLx : SubtargetFeature<"slowfpvmlx", "SlowFPVMLx", "true",
|
|
|
|
|
"Disable VFP / NEON MAC instructions">;
|
2011-04-01 03:38:48 +08:00
|
|
|
|
2020-01-05 18:59:21 +08:00
|
|
|
// VFPv4 added VFMA instructions that can similar be fast or slow.
|
|
|
|
|
def FeatureHasSlowFPVFMx : SubtargetFeature<"slowfpvfmx", "SlowFPVFMx", "true",
|
|
|
|
|
"Disable VFP / NEON FMA instructions">;
|
|
|
|
|
|
2011-04-01 03:38:48 +08:00
|
|
|
// Cortex-A8 / A9 Advanced SIMD has multiplier accumulator forwarding.
|
|
|
|
|
def FeatureVMLxForwarding : SubtargetFeature<"vmlx-forwarding",
|
2017-07-13 18:24:30 +08:00
|
|
|
"HasVMLxForwarding", "true",
|
|
|
|
|
"Has multiplier accumulator forwarding">;
|
2011-04-01 03:38:48 +08:00
|
|
|
|
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">;
|
2010-03-26 07:11:16 +08:00
|
|
|
|
[LLVM][Alignment] Make functions using log of alignment explicit
Summary:
This patch renames functions that takes or returns alignment as log2, this patch will help with the transition to llvm::Align.
The renaming makes it explicit that we deal with log(alignment) instead of a power of two alignment.
A few renames uncovered dubious assignments:
- `MirParser`/`MirPrinter` was expecting powers of two but `MachineFunction` and `MachineBasicBlock` were using deal with log2(align). This patch fixes it and updates the documentation.
- `MachineBlockPlacement` exposes two flags (`align-all-blocks` and `align-all-nofallthru-blocks`) supposedly interpreted as power of two alignments, internally these values are interpreted as log2(align). This patch updates the documentation,
- `MachineFunctionexposes` exposes `align-all-functions` also interpreted as power of two alignment, internally this value is interpreted as log2(align). This patch updates the documentation,
Reviewers: lattner, thegameg, courbet
Subscribers: dschuff, arsenm, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, javed.absar, hiraditya, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, Jim, s.egerton, llvm-commits, courbet
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65945
llvm-svn: 371045
2019-09-05 18:00:22 +08:00
|
|
|
def FeaturePrefLoopAlign32 : SubtargetFeature<"loop-align", "PrefLoopLogAlignment","2",
|
2018-09-13 18:28:05 +08:00
|
|
|
"Prefer 32-bit alignment for loops">;
|
|
|
|
|
|
2019-08-14 02:12:08 +08:00
|
|
|
def FeatureMVEVectorCostFactor1 : SubtargetFeature<"mve1beat", "MVEVectorCostFactor", "1",
|
|
|
|
|
"Model MVE instructions as a 1 beat per tick architecture">;
|
|
|
|
|
|
|
|
|
|
def FeatureMVEVectorCostFactor2 : SubtargetFeature<"mve2beat", "MVEVectorCostFactor", "2",
|
|
|
|
|
"Model MVE instructions as a 2 beats per tick architecture">;
|
|
|
|
|
|
|
|
|
|
def FeatureMVEVectorCostFactor4 : SubtargetFeature<"mve4beat", "MVEVectorCostFactor", "4",
|
|
|
|
|
"Model MVE instructions as a 4 beats per tick architecture">;
|
|
|
|
|
|
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">;
|
|
|
|
|
|
2017-06-02 16:53:19 +08:00
|
|
|
/// Disable +1 predication cost for instructions updating CPSR.
|
|
|
|
|
/// Enabled for Cortex-A57.
|
|
|
|
|
def FeatureCheapPredicableCPSR : SubtargetFeature<"cheap-predicable-cpsr",
|
|
|
|
|
"CheapPredicableCPSRDef",
|
|
|
|
|
"true",
|
|
|
|
|
"Disable +1 predication cost for instructions updating CPSR">;
|
|
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureAvoidMOVsShOp : SubtargetFeature<"avoid-movs-shop",
|
|
|
|
|
"AvoidMOVsShifterOperand", "true",
|
|
|
|
|
"Avoid movs instructions with "
|
|
|
|
|
"shifter operand">;
|
2012-12-21 03:59:30 +08:00
|
|
|
|
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.
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureHasRetAddrStack : SubtargetFeature<"ret-addr-stack",
|
|
|
|
|
"HasRetAddrStack", "true",
|
|
|
|
|
"Has return address stack">;
|
2012-02-29 02:51:51 +08:00
|
|
|
|
2017-06-28 22:11:15 +08:00
|
|
|
// Some processors have no branch predictor, which changes the expected cost of
|
|
|
|
|
// taking a branch which affects the choice of whether to use predicated
|
|
|
|
|
// instructions.
|
|
|
|
|
def FeatureHasNoBranchPredictor : SubtargetFeature<"no-branch-predictor",
|
|
|
|
|
"HasBranchPredictor", "false",
|
|
|
|
|
"Has no branch predictor">;
|
|
|
|
|
|
2015-10-24 01:19:19 +08:00
|
|
|
/// DSP extension.
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureDSP : SubtargetFeature<"dsp", "HasDSP", "true",
|
|
|
|
|
"Supports DSP instructions in "
|
|
|
|
|
"ARM and/or Thumb2">;
|
2011-07-02 05:12:19 +08:00
|
|
|
|
2010-11-03 14:34:55 +08:00
|
|
|
// Multiprocessing extension.
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureMP : SubtargetFeature<"mp", "HasMPExtension", "true",
|
|
|
|
|
"Supports Multiprocessing extension">;
|
2010-08-11 14:51:54 +08:00
|
|
|
|
2013-11-01 21:27:35 +08:00
|
|
|
// Virtualization extension - requires HW divide (ARMv7-AR ARMARM - 4.4.8).
|
|
|
|
|
def FeatureVirtualization : SubtargetFeature<"virtualization",
|
2017-07-13 18:24:30 +08:00
|
|
|
"HasVirtualization", "true",
|
|
|
|
|
"Supports Virtualization extension",
|
|
|
|
|
[FeatureHWDivThumb, FeatureHWDivARM]>;
|
2013-11-01 21:27:35 +08:00
|
|
|
|
2017-07-13 18:24:30 +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">;
|
2011-09-28 22:21:38 +08:00
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureStrictAlign : SubtargetFeature<"strict-align",
|
|
|
|
|
"StrictAlign", "true",
|
|
|
|
|
"Disallow all unaligned memory "
|
|
|
|
|
"access">;
|
|
|
|
|
|
|
|
|
|
def FeatureLongCalls : SubtargetFeature<"long-calls", "GenLongCalls", "true",
|
|
|
|
|
"Generate calls via indirect call "
|
|
|
|
|
"instructions">;
|
|
|
|
|
|
|
|
|
|
def FeatureExecuteOnly : SubtargetFeature<"execute-only",
|
|
|
|
|
"GenExecuteOnly", "true",
|
|
|
|
|
"Enable the generation of "
|
|
|
|
|
"execute only code.">;
|
|
|
|
|
|
2019-11-30 01:01:05 +08:00
|
|
|
def FeatureReserveR9 : SubtargetFeature<"reserve-r9", "ReserveR9", "true",
|
|
|
|
|
"Reserve R9, making it unavailable"
|
|
|
|
|
" as GPR">;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
|
|
|
|
def FeatureNoMovt : SubtargetFeature<"no-movt", "NoMovt", "true",
|
|
|
|
|
"Don't use movt/movw pairs for "
|
|
|
|
|
"32-bit imms">;
|
|
|
|
|
|
|
|
|
|
def FeatureNoNegativeImmediates
|
|
|
|
|
: SubtargetFeature<"no-neg-immediates",
|
|
|
|
|
"NegativeImmediates", "false",
|
|
|
|
|
"Convert immediates and instructions "
|
|
|
|
|
"to their negated or complemented "
|
|
|
|
|
"equivalent when the immediate does "
|
|
|
|
|
"not fit in the encoding.">;
|
|
|
|
|
|
2017-07-28 03:56:44 +08:00
|
|
|
// Use the MachineScheduler for instruction scheduling for the subtarget.
|
|
|
|
|
def FeatureUseMISched: SubtargetFeature<"use-misched", "UseMISched", "true",
|
|
|
|
|
"Use the MachineScheduler">;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2017-08-31 16:57:51 +08:00
|
|
|
def FeatureNoPostRASched : SubtargetFeature<"disable-postra-scheduler",
|
|
|
|
|
"DisablePostRAScheduler", "true",
|
|
|
|
|
"Don't schedule again after register allocation">;
|
2017-08-18 22:27:51 +08:00
|
|
|
|
2018-09-27 21:41:14 +08:00
|
|
|
// Armv8.5-A extensions
|
|
|
|
|
|
2019-01-03 20:09:12 +08:00
|
|
|
def FeatureSB : SubtargetFeature<"sb", "HasSB", "true",
|
|
|
|
|
"Enable v8.5a Speculation Barrier" >;
|
2018-09-27 21:41:14 +08:00
|
|
|
|
[PATCH] [ARM] ARMv8.6-a command-line + BFloat16 Asm Support
Summary:
This patch introduces command-line support for the Armv8.6-a architecture and assembly support for BFloat16. Details can be found
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a
in addition to the GCC patch for the 8..6-a CLI:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg02647.html
In detail this patch
- march options for armv8.6-a
- BFloat16 assembly
This is part of a patch series, starting with command-line and Bfloat16
assembly support. The subsequent patches will upstream intrinsics
support for BFloat16, followed by Matrix Multiplication and the
remaining Virtualization features of the armv8.6-a architecture.
Based on work by:
- labrinea
- MarkMurrayARM
- Luke Cheeseman
- Javed Asbar
- Mikhail Maltsev
- Luke Geeson
Reviewers: SjoerdMeijer, craig.topper, rjmccall, jfb, LukeGeeson
Reviewed By: SjoerdMeijer
Subscribers: stuij, kristof.beyls, hiraditya, dexonsmith, danielkiss, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D76062
2020-03-26 16:17:29 +08:00
|
|
|
// Armv8.6-A extensions
|
|
|
|
|
def FeatureBF16 : SubtargetFeature<"bf16", "HasBF16", "true",
|
|
|
|
|
"Enable support for BFloat16 instructions", [FeatureNEON]>;
|
|
|
|
|
|
2020-04-10 02:29:19 +08:00
|
|
|
def FeatureMatMulInt8 : SubtargetFeature<"i8mm", "HasMatMulInt8",
|
|
|
|
|
"true", "Enable Matrix Multiply Int8 Extension", [FeatureNEON]>;
|
|
|
|
|
|
[ARM] Add the non-MVE instructions in Arm v8.1-M.
This adds support for the new family of conditional selection /
increment / negation instructions; the low-overhead branch
instructions (e.g. BF, WLS, DLS); the CLRM instruction to zero a whole
list of registers at once; the new VMRS/VMSR and VLDR/VSTR
instructions to get data in and out of 8.1-M system registers,
particularly including the new VPR register used by MVE vector
predication.
To support this, we also add a register name 'zr' (used by the CSEL
family to force one of the inputs to the constant 0), and operand
types for lists of registers that are also allowed to include APSR or
VPR (used by CLRM). The VLDR/VSTR instructions also need a new
addressing mode.
The low-overhead branch instructions exist in their own separate
architecture extension, which we treat as enabled by default, but you
can say -mattr=-lob or equivalent to turn it off.
Reviewers: dmgreen, samparker, SjoerdMeijer, t.p.northover
Reviewed By: samparker
Subscribers: miyuki, javed.absar, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62667
llvm-svn: 363039
2019-06-11 17:29:18 +08:00
|
|
|
// Armv8.1-M extensions
|
|
|
|
|
|
|
|
|
|
def FeatureLOB : SubtargetFeature<"lob", "HasLOB", "true",
|
|
|
|
|
"Enable Low Overhead Branch "
|
|
|
|
|
"extensions">;
|
|
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// ARM architecture class
|
|
|
|
|
//
|
2013-09-23 22:26:15 +08:00
|
|
|
|
|
|
|
|
// A-series ISA
|
|
|
|
|
def FeatureAClass : SubtargetFeature<"aclass", "ARMProcClass", "AClass",
|
|
|
|
|
"Is application profile ('A' series)">;
|
|
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
// R-series ISA
|
|
|
|
|
def FeatureRClass : SubtargetFeature<"rclass", "ARMProcClass", "RClass",
|
|
|
|
|
"Is realtime profile ('R' series)">;
|
2015-07-29 06:44:28 +08:00
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
// M-series ISA
|
|
|
|
|
def FeatureMClass : SubtargetFeature<"mclass", "ARMProcClass", "MClass",
|
|
|
|
|
"Is microcontroller profile ('M' series)">;
|
2015-07-07 14:54:42 +08:00
|
|
|
|
2017-07-01 10:55:22 +08:00
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureThumb2 : SubtargetFeature<"thumb2", "HasThumb2", "true",
|
|
|
|
|
"Enable Thumb2 instructions">;
|
2015-07-21 09:42:02 +08:00
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
def FeatureNoARM : SubtargetFeature<"noarm", "NoARM", "true",
|
[ARM] Remove FeatureNoARM implies ModeThumb.
Summary:
By removing FeatureNoARM implies ModeThumb, we can detect cases where a
function's target-features contain -thumb-mode (enables ARM codegen for the
function), but the architecture does not support ARM mode. Previously, the
implication caused the FeatureNoARM bit to be cleared for functions with
-thumb-mode, making the assertion in ARMSubtarget::ARMSubtarget [1]
pointless for such functions.
This assertion is the only guard against generating ARM code for
architectures without ARM codegen support. Is there a place where we
could easily generate error messages for the user? At the moment, we
would generate ARM code for Thumb-only architectures. X86 has the same
behavior as ARM, as in it only has an assertion and no error message,
but I think for ARM an error message would be helpful. What do you
think?
For the example below, `llc -mtriple=armv7m-eabi test.ll -o -` will
generate ARM assembler (or fail with an assertion error with this patch).
Note that if we run the resulting assembler through llvm-mc, we get
an appropriate error message, but not when codegen is handled
through clang.
```
define void @bar() #0 {
entry:
ret void
}
attributes #0 = { "target-features"="-thumb-mode" }
```
[1] https://github.com/llvm-mirror/llvm/blob/c1f7b54cef62e9c8aa745d40bea146a167bf844e/lib/Target/ARM/ARMSubtarget.cpp#L147
Reviewers: t.p.northover, rengolin, peter.smith, aadg, silviu.baranga, richard.barton.arm, echristo
Reviewed By: rengolin, echristo
Subscribers: efriedma, aemerson, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D35569
llvm-svn: 310476
2017-08-09 21:53:28 +08:00
|
|
|
"Does not support ARM mode execution">;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// ARM ISAa.
|
|
|
|
|
//
|
|
|
|
|
|
2011-07-07 11:55:05 +08:00
|
|
|
def HasV4TOps : SubtargetFeature<"v4t", "HasV4TOps", "true",
|
2011-07-07 16:26:46 +08:00
|
|
|
"Support ARM v4T instructions">;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2011-07-07 11:55:05 +08:00
|
|
|
def HasV5TOps : SubtargetFeature<"v5t", "HasV5TOps", "true",
|
2011-07-07 16:26:46 +08:00
|
|
|
"Support ARM v5T instructions",
|
2011-07-07 11:55:05 +08:00
|
|
|
[HasV4TOps]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2011-07-07 11:55:05 +08:00
|
|
|
def HasV5TEOps : SubtargetFeature<"v5te", "HasV5TEOps", "true",
|
2017-07-13 18:24:30 +08:00
|
|
|
"Support ARM v5TE, v5TEj, and "
|
|
|
|
|
"v5TExp instructions",
|
2011-07-07 11:55:05 +08:00
|
|
|
[HasV5TOps]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2011-07-07 11:55:05 +08:00
|
|
|
def HasV6Ops : SubtargetFeature<"v6", "HasV6Ops", "true",
|
2011-07-07 16:26:46 +08:00
|
|
|
"Support ARM v6 instructions",
|
2011-07-07 11:55:05 +08:00
|
|
|
[HasV5TEOps]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2013-10-07 19:10:47 +08:00
|
|
|
def HasV6MOps : SubtargetFeature<"v6m", "HasV6MOps", "true",
|
|
|
|
|
"Support ARM v6M instructions",
|
|
|
|
|
[HasV6Ops]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2016-01-15 18:24:39 +08:00
|
|
|
def HasV8MBaselineOps : SubtargetFeature<"v8m", "HasV8MBaselineOps", "true",
|
|
|
|
|
"Support ARM v8M Baseline instructions",
|
|
|
|
|
[HasV6MOps]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2015-03-17 19:55:28 +08:00
|
|
|
def HasV6KOps : SubtargetFeature<"v6k", "HasV6KOps", "true",
|
|
|
|
|
"Support ARM v6k instructions",
|
|
|
|
|
[HasV6Ops]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2011-07-07 11:55:05 +08:00
|
|
|
def HasV6T2Ops : SubtargetFeature<"v6t2", "HasV6T2Ops", "true",
|
2011-07-07 16:26:46 +08:00
|
|
|
"Support ARM v6t2 instructions",
|
2016-01-15 18:24:39 +08:00
|
|
|
[HasV8MBaselineOps, HasV6KOps, FeatureThumb2]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2011-07-07 11:55:05 +08:00
|
|
|
def HasV7Ops : SubtargetFeature<"v7", "HasV7Ops", "true",
|
2011-07-07 16:26:46 +08:00
|
|
|
"Support ARM v7 instructions",
|
2016-01-15 18:23:46 +08:00
|
|
|
[HasV6T2Ops, FeaturePerfMon,
|
|
|
|
|
FeatureV7Clrex]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
|
|
|
|
def HasV8MMainlineOps :
|
|
|
|
|
SubtargetFeature<"v8m.main", "HasV8MMainlineOps", "true",
|
|
|
|
|
"Support ARM v8M Mainline instructions",
|
|
|
|
|
[HasV7Ops]>;
|
|
|
|
|
|
2013-06-27 00:58:26 +08:00
|
|
|
def HasV8Ops : SubtargetFeature<"v8", "HasV8Ops", "true",
|
|
|
|
|
"Support ARM v8 instructions",
|
2017-02-17 23:42:44 +08:00
|
|
|
[HasV7Ops, FeatureAcquireRelease]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2015-04-01 22:54:56 +08:00
|
|
|
def HasV8_1aOps : SubtargetFeature<"v8.1a", "HasV8_1aOps", "true",
|
2015-03-27 01:05:54 +08:00
|
|
|
"Support ARM v8.1a instructions",
|
2015-11-16 19:10:19 +08:00
|
|
|
[HasV8Ops]>;
|
2017-07-13 18:24:30 +08:00
|
|
|
|
|
|
|
|
def HasV8_2aOps : SubtargetFeature<"v8.2a", "HasV8_2aOps", "true",
|
2015-12-01 18:23:06 +08:00
|
|
|
"Support ARM v8.2a instructions",
|
|
|
|
|
[HasV8_1aOps]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
2017-08-10 17:41:00 +08:00
|
|
|
def HasV8_3aOps : SubtargetFeature<"v8.3a", "HasV8_3aOps", "true",
|
|
|
|
|
"Support ARM v8.3a instructions",
|
|
|
|
|
[HasV8_2aOps]>;
|
2010-08-11 14:51:54 +08:00
|
|
|
|
[ARM][AArch64] Armv8.4-A Enablement
Initial patch adding assembly support for Armv8.4-A.
Besides adding v8.4 as a supported architecture to the usual places, this also
adds target features for the different crypto algorithms. Armv8.4-A introduced
new crypto algorithms, made them optional, and allows different combinations:
- none of the v8.4 crypto functions are supported, which is independent of the
implementation of the Armv8.0 SHA1 and SHA2 instructions.
- the v8.4 SHA512 and SHA3 support is implemented, in this case the Armv8.0
SHA1 and SHA2 instructions must also be implemented.
- the v8.4 SM3 and SM4 support is implemented, which is independent of the
implementation of the Armv8.0 SHA1 and SHA2 instructions.
- all of the v8.4 crypto functions are supported, in this case the Armv8.0 SHA1
and SHA2 instructions must also be implemented.
The v8.4 crypto instructions are added to AArch64 only, and not AArch32,
and are made optional extensions to Armv8.2-A.
The user-facing Clang options will map on these new target features, their
naming will be compatible with GCC and added in follow-up patches.
The Armv8.4-A instruction sets can be downloaded here:
https://developer.arm.com/products/architecture/a-profile/exploration-tools
Differential Revision: https://reviews.llvm.org/D48625
llvm-svn: 335953
2018-06-29 16:43:19 +08:00
|
|
|
def HasV8_4aOps : SubtargetFeature<"v8.4a", "HasV8_4aOps", "true",
|
|
|
|
|
"Support ARM v8.4a instructions",
|
|
|
|
|
[HasV8_3aOps, FeatureDotProd]>;
|
|
|
|
|
|
2018-09-26 20:48:21 +08:00
|
|
|
def HasV8_5aOps : SubtargetFeature<"v8.5a", "HasV8_5aOps", "true",
|
|
|
|
|
"Support ARM v8.5a instructions",
|
2019-01-03 20:09:12 +08:00
|
|
|
[HasV8_4aOps, FeatureSB]>;
|
2018-09-26 20:48:21 +08:00
|
|
|
|
[PATCH] [ARM] ARMv8.6-a command-line + BFloat16 Asm Support
Summary:
This patch introduces command-line support for the Armv8.6-a architecture and assembly support for BFloat16. Details can be found
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a
in addition to the GCC patch for the 8..6-a CLI:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg02647.html
In detail this patch
- march options for armv8.6-a
- BFloat16 assembly
This is part of a patch series, starting with command-line and Bfloat16
assembly support. The subsequent patches will upstream intrinsics
support for BFloat16, followed by Matrix Multiplication and the
remaining Virtualization features of the armv8.6-a architecture.
Based on work by:
- labrinea
- MarkMurrayARM
- Luke Cheeseman
- Javed Asbar
- Mikhail Maltsev
- Luke Geeson
Reviewers: SjoerdMeijer, craig.topper, rjmccall, jfb, LukeGeeson
Reviewed By: SjoerdMeijer
Subscribers: stuij, kristof.beyls, hiraditya, dexonsmith, danielkiss, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D76062
2020-03-26 16:17:29 +08:00
|
|
|
def HasV8_6aOps : SubtargetFeature<"v8.6a", "HasV8_6aOps", "true",
|
|
|
|
|
"Support ARM v8.6a instructions",
|
2020-04-10 02:29:19 +08:00
|
|
|
[HasV8_5aOps, FeatureBF16,
|
|
|
|
|
FeatureMatMulInt8]>;
|
[PATCH] [ARM] ARMv8.6-a command-line + BFloat16 Asm Support
Summary:
This patch introduces command-line support for the Armv8.6-a architecture and assembly support for BFloat16. Details can be found
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a
in addition to the GCC patch for the 8..6-a CLI:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg02647.html
In detail this patch
- march options for armv8.6-a
- BFloat16 assembly
This is part of a patch series, starting with command-line and Bfloat16
assembly support. The subsequent patches will upstream intrinsics
support for BFloat16, followed by Matrix Multiplication and the
remaining Virtualization features of the armv8.6-a architecture.
Based on work by:
- labrinea
- MarkMurrayARM
- Luke Cheeseman
- Javed Asbar
- Mikhail Maltsev
- Luke Geeson
Reviewers: SjoerdMeijer, craig.topper, rjmccall, jfb, LukeGeeson
Reviewed By: SjoerdMeijer
Subscribers: stuij, kristof.beyls, hiraditya, dexonsmith, danielkiss, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D76062
2020-03-26 16:17:29 +08:00
|
|
|
|
2019-05-30 20:57:04 +08:00
|
|
|
def HasV8_1MMainlineOps : SubtargetFeature<
|
|
|
|
|
"v8.1m.main", "HasV8_1MMainlineOps", "true",
|
|
|
|
|
"Support ARM v8-1M Mainline instructions",
|
|
|
|
|
[HasV8MMainlineOps]>;
|
|
|
|
|
def HasMVEIntegerOps : SubtargetFeature<
|
|
|
|
|
"mve", "HasMVEIntegerOps", "true",
|
|
|
|
|
"Support M-Class Vector Extension with integer ops",
|
|
|
|
|
[HasV8_1MMainlineOps, FeatureDSP, FeatureFPRegs16, FeatureFPRegs64]>;
|
|
|
|
|
def HasMVEFloatOps : SubtargetFeature<
|
|
|
|
|
"mve.fp", "HasMVEFloatOps", "true",
|
|
|
|
|
"Support M-Class Vector Extension with integer and floating ops",
|
|
|
|
|
[HasMVEIntegerOps, FeatureFPARMv8_D16_SP, FeatureFullFP16]>;
|
|
|
|
|
|
[ARM] Add initial support for Custom Datapath Extension (CDE)
Summary:
This patch adds assembly-level support for a new Arm M-profile
architecture extension, Custom Datapath Extension (CDE).
A brief description of the extension is available at
https://developer.arm.com/architectures/instruction-sets/custom-instructions
The latest specification for CDE is currently a beta release and is
available at
https://static.docs.arm.com/ddi0607/aa/DDI0607A_a_armv8m_arm_supplement_cde.pdf
CDE allows chip vendors to add custom CPU instructions. The CDE
instructions re-use the same encoding space as existing coprocessor
instructions (such as MRC, MCR, CDP etc.). Each coprocessor in range
cp0-cp7 can be configured as either general purpose (GCP) or custom
datapath (CDEv1). This configuration is defined by the CPU vendor and
is provided to LLVM using 8 subtarget features: cdecp0 ... cdecp7.
The semantics of CDE instructions are implementation-defined, but the
instructions are guaranteed to be pure (that is, they are stateless,
they do not access memory or any registers except their explicit
inputs/outputs).
CDE requires the CPU to support at least Armv8.0-M mainline
architecture. CDE includes 3 sets of instructions:
* Instructions that operate on general purpose registers and NZCV
flags
* Instructions that operate on the S or D register file (require
either FP or MVE extension)
* Instructions that operate on the Q register file, require MVE
The user-facing names that can be specified on the command line are
the same as the 8 subtarget feature names. For example:
$ clang -target arm-none-none-eabi -march=armv8m.main+cdecp0+cdecp3
tells the compiler that the coprocessors 0 and 3 are configured as
CDEv1 and the remaining coprocessors are configured as GCP (which is
the default).
Reviewers: simon_tatham, ostannard, dmgreen, eli.friedman
Reviewed By: simon_tatham
Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D74044
2020-02-17 23:37:49 +08:00
|
|
|
def HasCDEOps : SubtargetFeature<"cde", "HasCDEOps", "true",
|
|
|
|
|
"Support CDE instructions",
|
|
|
|
|
[HasV8MMainlineOps]>;
|
|
|
|
|
|
|
|
|
|
foreach i = {0-7} in
|
|
|
|
|
def FeatureCoprocCDE#i : SubtargetFeature<"cdecp"#i,
|
|
|
|
|
"CoprocCDE["#i#"]", "true",
|
|
|
|
|
"Coprocessor "#i#" ISA is CDEv1",
|
|
|
|
|
[HasCDEOps]>;
|
|
|
|
|
|
2007-01-19 15:51:42 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2015-11-16 19:10:19 +08:00
|
|
|
// ARM Processor subtarget features.
|
2007-01-19 15:51:42 +08:00
|
|
|
//
|
|
|
|
|
|
2012-11-30 03:48:01 +08:00
|
|
|
def ProcA5 : SubtargetFeature<"a5", "ARMProcFamily", "CortexA5",
|
2015-11-16 19:10:19 +08:00
|
|
|
"Cortex-A5 ARM processors", []>;
|
2013-11-21 22:03:21 +08:00
|
|
|
def ProcA7 : SubtargetFeature<"a7", "ARMProcFamily", "CortexA7",
|
2015-11-16 19:10:19 +08:00
|
|
|
"Cortex-A7 ARM processors", []>;
|
2010-09-10 09:29:16 +08:00
|
|
|
def ProcA8 : SubtargetFeature<"a8", "ARMProcFamily", "CortexA8",
|
2015-11-16 19:10:19 +08:00
|
|
|
"Cortex-A8 ARM processors", []>;
|
2010-09-10 09:29:16 +08:00
|
|
|
def ProcA9 : SubtargetFeature<"a9", "ARMProcFamily", "CortexA9",
|
2015-11-16 19:10:19 +08:00
|
|
|
"Cortex-A9 ARM processors", []>;
|
2013-11-22 19:53:16 +08:00
|
|
|
def ProcA12 : SubtargetFeature<"a12", "ARMProcFamily", "CortexA12",
|
2015-11-16 19:10:19 +08:00
|
|
|
"Cortex-A12 ARM processors", []>;
|
|
|
|
|
def ProcA15 : SubtargetFeature<"a15", "ARMProcFamily", "CortexA15",
|
|
|
|
|
"Cortex-A15 ARM processors", []>;
|
2014-10-13 18:22:19 +08:00
|
|
|
def ProcA17 : SubtargetFeature<"a17", "ARMProcFamily", "CortexA17",
|
2015-11-16 19:10:19 +08:00
|
|
|
"Cortex-A17 ARM processors", []>;
|
2016-03-22 01:29:01 +08:00
|
|
|
def ProcA32 : SubtargetFeature<"a32", "ARMProcFamily", "CortexA32",
|
|
|
|
|
"Cortex-A32 ARM processors", []>;
|
2015-12-02 19:53:44 +08:00
|
|
|
def ProcA35 : SubtargetFeature<"a35", "ARMProcFamily", "CortexA35",
|
|
|
|
|
"Cortex-A35 ARM processors", []>;
|
2013-10-14 21:16:57 +08:00
|
|
|
def ProcA53 : SubtargetFeature<"a53", "ARMProcFamily", "CortexA53",
|
2015-11-16 19:10:19 +08:00
|
|
|
"Cortex-A53 ARM processors", []>;
|
2017-08-21 16:43:06 +08:00
|
|
|
def ProcA55 : SubtargetFeature<"a55", "ARMProcFamily", "CortexA55",
|
|
|
|
|
"Cortex-A55 ARM processors", []>;
|
2013-10-14 21:17:07 +08:00
|
|
|
def ProcA57 : SubtargetFeature<"a57", "ARMProcFamily", "CortexA57",
|
2015-11-16 19:10:19 +08:00
|
|
|
"Cortex-A57 ARM processors", []>;
|
|
|
|
|
def ProcA72 : SubtargetFeature<"a72", "ARMProcFamily", "CortexA72",
|
|
|
|
|
"Cortex-A72 ARM processors", []>;
|
2016-06-02 18:48:52 +08:00
|
|
|
def ProcA73 : SubtargetFeature<"a73", "ARMProcFamily", "CortexA73",
|
|
|
|
|
"Cortex-A73 ARM processors", []>;
|
2017-08-21 16:43:06 +08:00
|
|
|
def ProcA75 : SubtargetFeature<"a75", "ARMProcFamily", "CortexA75",
|
|
|
|
|
"Cortex-A75 ARM processors", []>;
|
2019-02-25 23:08:27 +08:00
|
|
|
def ProcA76 : SubtargetFeature<"a76", "ARMProcFamily", "CortexA76",
|
|
|
|
|
"Cortex-A76 ARM processors", []>;
|
[ARM] Add Cortex-A77 Support for Clang and LLVM
This patch upstreams support for the Arm-v8 Cortex-A77
processor for AArch64 and ARM.
In detail:
- Adding cortex-a77 as a cpu option for aarch64 and arm targets in clang
- Cortex-A77 CPU name and ProcessorModel in llvm
details of the CPU can be found here:
https://www.arm.com/products/silicon-ip-cpu/cortex-a/cortex-a77
and a similar submission to GCC can be found here:
https://github.com/gcc-mirror/gcc/commit/e0664b7a63ed8305e9f8539309df7fb3eb13babe
The following people contributed to this patch:
- Luke Geeson
- Mikhail Maltsev
Reviewers: t.p.northover, dmgreen, ostannard, SjoerdMeijer
Reviewed By: dmgreen
Subscribers: dmgreen, kristof.beyls, hiraditya, danielkiss, cfe-commits,
llvm-commits, miyuki
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D82887
2020-06-30 23:45:36 +08:00
|
|
|
def ProcA77 : SubtargetFeature<"a77", "ARMProcFamily", "CortexA77",
|
|
|
|
|
"Cortex-A77 ARM processors", []>;
|
2020-07-01 19:50:36 +08:00
|
|
|
def ProcA78 : SubtargetFeature<"cortex-a78", "ARMProcFamily", "CortexA78",
|
|
|
|
|
"Cortex-A78 ARM processors", []>;
|
|
|
|
|
def ProcX1 : SubtargetFeature<"cortex-x1", "ARMProcFamily", "CortexX1",
|
|
|
|
|
"Cortex-X1 ARM processors", []>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
|
|
|
|
def ProcKrait : SubtargetFeature<"krait", "ARMProcFamily", "Krait",
|
2017-04-07 06:47:47 +08:00
|
|
|
"Qualcomm Krait processors", []>;
|
|
|
|
|
def ProcKryo : SubtargetFeature<"kryo", "ARMProcFamily", "Kryo",
|
|
|
|
|
"Qualcomm Kryo processors", []>;
|
2015-11-16 19:10:19 +08:00
|
|
|
def ProcSwift : SubtargetFeature<"swift", "ARMProcFamily", "Swift",
|
|
|
|
|
"Swift ARM processors", []>;
|
2013-10-14 21:17:07 +08:00
|
|
|
|
2018-09-20 03:43:23 +08:00
|
|
|
def ProcExynos : SubtargetFeature<"exynos", "ARMProcFamily", "Exynos",
|
|
|
|
|
"Samsung Exynos processors",
|
|
|
|
|
[FeatureZCZeroing,
|
|
|
|
|
FeatureUseWideStrideVFP,
|
|
|
|
|
FeatureSplatVFPToNeon,
|
|
|
|
|
FeatureSlowVGETLNi32,
|
|
|
|
|
FeatureSlowVDUP32,
|
|
|
|
|
FeatureSlowFPBrcc,
|
|
|
|
|
FeatureProfUnpredicate,
|
|
|
|
|
FeatureHWDivThumb,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
2018-09-20 03:43:23 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2018-09-25 00:35:09 +08:00
|
|
|
FeatureFuseLiterals,
|
|
|
|
|
FeatureFuseAES,
|
2018-09-20 03:43:23 +08:00
|
|
|
FeatureExpandMLx,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC]>;
|
2015-04-09 22:07:28 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def ProcR4 : SubtargetFeature<"r4", "ARMProcFamily", "CortexR4",
|
2016-01-15 18:23:46 +08:00
|
|
|
"Cortex-R4 ARM processors", []>;
|
2012-12-21 12:35:05 +08:00
|
|
|
def ProcR5 : SubtargetFeature<"r5", "ARMProcFamily", "CortexR5",
|
2015-11-16 19:10:19 +08:00
|
|
|
"Cortex-R5 ARM processors", []>;
|
|
|
|
|
def ProcR7 : SubtargetFeature<"r7", "ARMProcFamily", "CortexR7",
|
|
|
|
|
"Cortex-R7 ARM processors", []>;
|
2016-10-07 20:06:40 +08:00
|
|
|
def ProcR52 : SubtargetFeature<"r52", "ARMProcFamily", "CortexR52",
|
|
|
|
|
"Cortex-R52 ARM processors", []>;
|
2013-12-07 06:48:17 +08:00
|
|
|
|
2016-03-24 00:18:13 +08:00
|
|
|
def ProcM3 : SubtargetFeature<"m3", "ARMProcFamily", "CortexM3",
|
|
|
|
|
"Cortex-M3 ARM processors", []>;
|
2014-01-02 21:40:08 +08:00
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2017-07-13 18:24:30 +08:00
|
|
|
// ARM Helper classes.
|
2015-11-16 19:10:19 +08:00
|
|
|
//
|
|
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
class Architecture<string fname, string aname, list<SubtargetFeature> features>
|
|
|
|
|
: SubtargetFeature<fname, "ARMArch", aname,
|
|
|
|
|
!strconcat(aname, " architecture"), features>;
|
|
|
|
|
|
|
|
|
|
class ProcNoItin<string Name, list<SubtargetFeature> Features>
|
|
|
|
|
: Processor<Name, NoItineraries, Features>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// ARM architectures
|
|
|
|
|
//
|
|
|
|
|
|
|
|
|
|
def ARMv2 : Architecture<"armv2", "ARMv2", []>;
|
|
|
|
|
|
|
|
|
|
def ARMv2a : Architecture<"armv2a", "ARMv2a", []>;
|
|
|
|
|
|
|
|
|
|
def ARMv3 : Architecture<"armv3", "ARMv3", []>;
|
|
|
|
|
|
|
|
|
|
def ARMv3m : Architecture<"armv3m", "ARMv3m", []>;
|
|
|
|
|
|
|
|
|
|
def ARMv4 : Architecture<"armv4", "ARMv4", []>;
|
|
|
|
|
|
|
|
|
|
def ARMv4t : Architecture<"armv4t", "ARMv4t", [HasV4TOps]>;
|
|
|
|
|
|
|
|
|
|
def ARMv5t : Architecture<"armv5t", "ARMv5t", [HasV5TOps]>;
|
|
|
|
|
|
|
|
|
|
def ARMv5te : Architecture<"armv5te", "ARMv5te", [HasV5TEOps]>;
|
|
|
|
|
|
|
|
|
|
def ARMv5tej : Architecture<"armv5tej", "ARMv5tej", [HasV5TEOps]>;
|
|
|
|
|
|
2018-01-12 17:21:09 +08:00
|
|
|
def ARMv6 : Architecture<"armv6", "ARMv6", [HasV6Ops,
|
|
|
|
|
FeatureDSP]>;
|
2007-01-19 15:51:42 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def ARMv6t2 : Architecture<"armv6t2", "ARMv6t2", [HasV6T2Ops,
|
2017-02-17 23:42:44 +08:00
|
|
|
FeatureDSP]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
|
|
|
|
def ARMv6k : Architecture<"armv6k", "ARMv6k", [HasV6KOps]>;
|
|
|
|
|
|
2015-11-16 22:05:32 +08:00
|
|
|
def ARMv6kz : Architecture<"armv6kz", "ARMv6kz", [HasV6KOps,
|
2015-10-29 21:56:19 +08:00
|
|
|
FeatureTrustZone]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
|
|
|
|
def ARMv6m : Architecture<"armv6-m", "ARMv6m", [HasV6MOps,
|
|
|
|
|
FeatureNoARM,
|
[ARM] Remove FeatureNoARM implies ModeThumb.
Summary:
By removing FeatureNoARM implies ModeThumb, we can detect cases where a
function's target-features contain -thumb-mode (enables ARM codegen for the
function), but the architecture does not support ARM mode. Previously, the
implication caused the FeatureNoARM bit to be cleared for functions with
-thumb-mode, making the assertion in ARMSubtarget::ARMSubtarget [1]
pointless for such functions.
This assertion is the only guard against generating ARM code for
architectures without ARM codegen support. Is there a place where we
could easily generate error messages for the user? At the moment, we
would generate ARM code for Thumb-only architectures. X86 has the same
behavior as ARM, as in it only has an assertion and no error message,
but I think for ARM an error message would be helpful. What do you
think?
For the example below, `llc -mtriple=armv7m-eabi test.ll -o -` will
generate ARM assembler (or fail with an assertion error with this patch).
Note that if we run the resulting assembler through llvm-mc, we get
an appropriate error message, but not when codegen is handled
through clang.
```
define void @bar() #0 {
entry:
ret void
}
attributes #0 = { "target-features"="-thumb-mode" }
```
[1] https://github.com/llvm-mirror/llvm/blob/c1f7b54cef62e9c8aa745d40bea146a167bf844e/lib/Target/ARM/ARMSubtarget.cpp#L147
Reviewers: t.p.northover, rengolin, peter.smith, aadg, silviu.baranga, richard.barton.arm, echristo
Reviewed By: rengolin, echristo
Subscribers: efriedma, aemerson, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D35569
llvm-svn: 310476
2017-08-09 21:53:28 +08:00
|
|
|
ModeThumb,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureDB,
|
2018-06-22 18:03:03 +08:00
|
|
|
FeatureMClass,
|
|
|
|
|
FeatureStrictAlign]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
|
|
|
|
def ARMv6sm : Architecture<"armv6s-m", "ARMv6sm", [HasV6MOps,
|
|
|
|
|
FeatureNoARM,
|
[ARM] Remove FeatureNoARM implies ModeThumb.
Summary:
By removing FeatureNoARM implies ModeThumb, we can detect cases where a
function's target-features contain -thumb-mode (enables ARM codegen for the
function), but the architecture does not support ARM mode. Previously, the
implication caused the FeatureNoARM bit to be cleared for functions with
-thumb-mode, making the assertion in ARMSubtarget::ARMSubtarget [1]
pointless for such functions.
This assertion is the only guard against generating ARM code for
architectures without ARM codegen support. Is there a place where we
could easily generate error messages for the user? At the moment, we
would generate ARM code for Thumb-only architectures. X86 has the same
behavior as ARM, as in it only has an assertion and no error message,
but I think for ARM an error message would be helpful. What do you
think?
For the example below, `llc -mtriple=armv7m-eabi test.ll -o -` will
generate ARM assembler (or fail with an assertion error with this patch).
Note that if we run the resulting assembler through llvm-mc, we get
an appropriate error message, but not when codegen is handled
through clang.
```
define void @bar() #0 {
entry:
ret void
}
attributes #0 = { "target-features"="-thumb-mode" }
```
[1] https://github.com/llvm-mirror/llvm/blob/c1f7b54cef62e9c8aa745d40bea146a167bf844e/lib/Target/ARM/ARMSubtarget.cpp#L147
Reviewers: t.p.northover, rengolin, peter.smith, aadg, silviu.baranga, richard.barton.arm, echristo
Reviewed By: rengolin, echristo
Subscribers: efriedma, aemerson, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D35569
llvm-svn: 310476
2017-08-09 21:53:28 +08:00
|
|
|
ModeThumb,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureDB,
|
2018-06-22 18:03:03 +08:00
|
|
|
FeatureMClass,
|
|
|
|
|
FeatureStrictAlign]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
|
|
|
|
def ARMv7a : Architecture<"armv7-a", "ARMv7a", [HasV7Ops,
|
|
|
|
|
FeatureNEON,
|
|
|
|
|
FeatureDB,
|
|
|
|
|
FeatureDSP,
|
2017-02-17 23:42:44 +08:00
|
|
|
FeatureAClass]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
2017-02-10 07:29:14 +08:00
|
|
|
def ARMv7ve : Architecture<"armv7ve", "ARMv7ve", [HasV7Ops,
|
|
|
|
|
FeatureNEON,
|
|
|
|
|
FeatureDB,
|
|
|
|
|
FeatureDSP,
|
|
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureMP,
|
|
|
|
|
FeatureVirtualization,
|
2017-02-17 23:42:44 +08:00
|
|
|
FeatureAClass]>;
|
2017-02-10 07:29:14 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def ARMv7r : Architecture<"armv7-r", "ARMv7r", [HasV7Ops,
|
|
|
|
|
FeatureDB,
|
|
|
|
|
FeatureDSP,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2017-02-17 23:42:44 +08:00
|
|
|
FeatureRClass]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
|
|
|
|
def ARMv7m : Architecture<"armv7-m", "ARMv7m", [HasV7Ops,
|
|
|
|
|
FeatureThumb2,
|
|
|
|
|
FeatureNoARM,
|
[ARM] Remove FeatureNoARM implies ModeThumb.
Summary:
By removing FeatureNoARM implies ModeThumb, we can detect cases where a
function's target-features contain -thumb-mode (enables ARM codegen for the
function), but the architecture does not support ARM mode. Previously, the
implication caused the FeatureNoARM bit to be cleared for functions with
-thumb-mode, making the assertion in ARMSubtarget::ARMSubtarget [1]
pointless for such functions.
This assertion is the only guard against generating ARM code for
architectures without ARM codegen support. Is there a place where we
could easily generate error messages for the user? At the moment, we
would generate ARM code for Thumb-only architectures. X86 has the same
behavior as ARM, as in it only has an assertion and no error message,
but I think for ARM an error message would be helpful. What do you
think?
For the example below, `llc -mtriple=armv7m-eabi test.ll -o -` will
generate ARM assembler (or fail with an assertion error with this patch).
Note that if we run the resulting assembler through llvm-mc, we get
an appropriate error message, but not when codegen is handled
through clang.
```
define void @bar() #0 {
entry:
ret void
}
attributes #0 = { "target-features"="-thumb-mode" }
```
[1] https://github.com/llvm-mirror/llvm/blob/c1f7b54cef62e9c8aa745d40bea146a167bf844e/lib/Target/ARM/ARMSubtarget.cpp#L147
Reviewers: t.p.northover, rengolin, peter.smith, aadg, silviu.baranga, richard.barton.arm, echristo
Reviewed By: rengolin, echristo
Subscribers: efriedma, aemerson, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D35569
llvm-svn: 310476
2017-08-09 21:53:28 +08:00
|
|
|
ModeThumb,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureDB,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureMClass]>;
|
|
|
|
|
|
|
|
|
|
def ARMv7em : Architecture<"armv7e-m", "ARMv7em", [HasV7Ops,
|
|
|
|
|
FeatureThumb2,
|
|
|
|
|
FeatureNoARM,
|
[ARM] Remove FeatureNoARM implies ModeThumb.
Summary:
By removing FeatureNoARM implies ModeThumb, we can detect cases where a
function's target-features contain -thumb-mode (enables ARM codegen for the
function), but the architecture does not support ARM mode. Previously, the
implication caused the FeatureNoARM bit to be cleared for functions with
-thumb-mode, making the assertion in ARMSubtarget::ARMSubtarget [1]
pointless for such functions.
This assertion is the only guard against generating ARM code for
architectures without ARM codegen support. Is there a place where we
could easily generate error messages for the user? At the moment, we
would generate ARM code for Thumb-only architectures. X86 has the same
behavior as ARM, as in it only has an assertion and no error message,
but I think for ARM an error message would be helpful. What do you
think?
For the example below, `llc -mtriple=armv7m-eabi test.ll -o -` will
generate ARM assembler (or fail with an assertion error with this patch).
Note that if we run the resulting assembler through llvm-mc, we get
an appropriate error message, but not when codegen is handled
through clang.
```
define void @bar() #0 {
entry:
ret void
}
attributes #0 = { "target-features"="-thumb-mode" }
```
[1] https://github.com/llvm-mirror/llvm/blob/c1f7b54cef62e9c8aa745d40bea146a167bf844e/lib/Target/ARM/ARMSubtarget.cpp#L147
Reviewers: t.p.northover, rengolin, peter.smith, aadg, silviu.baranga, richard.barton.arm, echristo
Reviewed By: rengolin, echristo
Subscribers: efriedma, aemerson, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D35569
llvm-svn: 310476
2017-08-09 21:53:28 +08:00
|
|
|
ModeThumb,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureDB,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureMClass,
|
2017-02-17 23:42:44 +08:00
|
|
|
FeatureDSP]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
|
|
|
|
def ARMv8a : Architecture<"armv8-a", "ARMv8a", [HasV8Ops,
|
|
|
|
|
FeatureAClass,
|
|
|
|
|
FeatureDB,
|
|
|
|
|
FeatureFPARMv8,
|
|
|
|
|
FeatureNEON,
|
|
|
|
|
FeatureDSP,
|
2015-10-29 21:56:19 +08:00
|
|
|
FeatureTrustZone,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureMP,
|
|
|
|
|
FeatureVirtualization,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC]>;
|
|
|
|
|
|
|
|
|
|
def ARMv81a : Architecture<"armv8.1-a", "ARMv81a", [HasV8_1aOps,
|
|
|
|
|
FeatureAClass,
|
|
|
|
|
FeatureDB,
|
|
|
|
|
FeatureFPARMv8,
|
|
|
|
|
FeatureNEON,
|
|
|
|
|
FeatureDSP,
|
|
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureMP,
|
|
|
|
|
FeatureVirtualization,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC]>;
|
|
|
|
|
|
2015-12-01 18:33:56 +08:00
|
|
|
def ARMv82a : Architecture<"armv8.2-a", "ARMv82a", [HasV8_2aOps,
|
|
|
|
|
FeatureAClass,
|
|
|
|
|
FeatureDB,
|
|
|
|
|
FeatureFPARMv8,
|
|
|
|
|
FeatureNEON,
|
|
|
|
|
FeatureDSP,
|
|
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureMP,
|
|
|
|
|
FeatureVirtualization,
|
|
|
|
|
FeatureCrypto,
|
2017-08-10 17:41:00 +08:00
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureRAS]>;
|
|
|
|
|
|
|
|
|
|
def ARMv83a : Architecture<"armv8.3-a", "ARMv83a", [HasV8_3aOps,
|
|
|
|
|
FeatureAClass,
|
|
|
|
|
FeatureDB,
|
|
|
|
|
FeatureFPARMv8,
|
|
|
|
|
FeatureNEON,
|
|
|
|
|
FeatureDSP,
|
|
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureMP,
|
|
|
|
|
FeatureVirtualization,
|
|
|
|
|
FeatureCrypto,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureRAS]>;
|
2015-12-01 18:33:56 +08:00
|
|
|
|
[ARM][AArch64] Armv8.4-A Enablement
Initial patch adding assembly support for Armv8.4-A.
Besides adding v8.4 as a supported architecture to the usual places, this also
adds target features for the different crypto algorithms. Armv8.4-A introduced
new crypto algorithms, made them optional, and allows different combinations:
- none of the v8.4 crypto functions are supported, which is independent of the
implementation of the Armv8.0 SHA1 and SHA2 instructions.
- the v8.4 SHA512 and SHA3 support is implemented, in this case the Armv8.0
SHA1 and SHA2 instructions must also be implemented.
- the v8.4 SM3 and SM4 support is implemented, which is independent of the
implementation of the Armv8.0 SHA1 and SHA2 instructions.
- all of the v8.4 crypto functions are supported, in this case the Armv8.0 SHA1
and SHA2 instructions must also be implemented.
The v8.4 crypto instructions are added to AArch64 only, and not AArch32,
and are made optional extensions to Armv8.2-A.
The user-facing Clang options will map on these new target features, their
naming will be compatible with GCC and added in follow-up patches.
The Armv8.4-A instruction sets can be downloaded here:
https://developer.arm.com/products/architecture/a-profile/exploration-tools
Differential Revision: https://reviews.llvm.org/D48625
llvm-svn: 335953
2018-06-29 16:43:19 +08:00
|
|
|
def ARMv84a : Architecture<"armv8.4-a", "ARMv84a", [HasV8_4aOps,
|
|
|
|
|
FeatureAClass,
|
|
|
|
|
FeatureDB,
|
|
|
|
|
FeatureFPARMv8,
|
|
|
|
|
FeatureNEON,
|
|
|
|
|
FeatureDSP,
|
|
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureMP,
|
|
|
|
|
FeatureVirtualization,
|
|
|
|
|
FeatureCrypto,
|
2018-09-26 20:48:21 +08:00
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureRAS,
|
|
|
|
|
FeatureDotProd]>;
|
|
|
|
|
|
|
|
|
|
def ARMv85a : Architecture<"armv8.5-a", "ARMv85a", [HasV8_5aOps,
|
|
|
|
|
FeatureAClass,
|
|
|
|
|
FeatureDB,
|
|
|
|
|
FeatureFPARMv8,
|
|
|
|
|
FeatureNEON,
|
|
|
|
|
FeatureDSP,
|
|
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureMP,
|
|
|
|
|
FeatureVirtualization,
|
|
|
|
|
FeatureCrypto,
|
[ARM][AArch64] Armv8.4-A Enablement
Initial patch adding assembly support for Armv8.4-A.
Besides adding v8.4 as a supported architecture to the usual places, this also
adds target features for the different crypto algorithms. Armv8.4-A introduced
new crypto algorithms, made them optional, and allows different combinations:
- none of the v8.4 crypto functions are supported, which is independent of the
implementation of the Armv8.0 SHA1 and SHA2 instructions.
- the v8.4 SHA512 and SHA3 support is implemented, in this case the Armv8.0
SHA1 and SHA2 instructions must also be implemented.
- the v8.4 SM3 and SM4 support is implemented, which is independent of the
implementation of the Armv8.0 SHA1 and SHA2 instructions.
- all of the v8.4 crypto functions are supported, in this case the Armv8.0 SHA1
and SHA2 instructions must also be implemented.
The v8.4 crypto instructions are added to AArch64 only, and not AArch32,
and are made optional extensions to Armv8.2-A.
The user-facing Clang options will map on these new target features, their
naming will be compatible with GCC and added in follow-up patches.
The Armv8.4-A instruction sets can be downloaded here:
https://developer.arm.com/products/architecture/a-profile/exploration-tools
Differential Revision: https://reviews.llvm.org/D48625
llvm-svn: 335953
2018-06-29 16:43:19 +08:00
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureRAS,
|
[PATCH] [ARM] ARMv8.6-a command-line + BFloat16 Asm Support
Summary:
This patch introduces command-line support for the Armv8.6-a architecture and assembly support for BFloat16. Details can be found
https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-architecture-developments-armv8-6-a
in addition to the GCC patch for the 8..6-a CLI:
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-11/msg02647.html
In detail this patch
- march options for armv8.6-a
- BFloat16 assembly
This is part of a patch series, starting with command-line and Bfloat16
assembly support. The subsequent patches will upstream intrinsics
support for BFloat16, followed by Matrix Multiplication and the
remaining Virtualization features of the armv8.6-a architecture.
Based on work by:
- labrinea
- MarkMurrayARM
- Luke Cheeseman
- Javed Asbar
- Mikhail Maltsev
- Luke Geeson
Reviewers: SjoerdMeijer, craig.topper, rjmccall, jfb, LukeGeeson
Reviewed By: SjoerdMeijer
Subscribers: stuij, kristof.beyls, hiraditya, dexonsmith, danielkiss, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D76062
2020-03-26 16:17:29 +08:00
|
|
|
FeatureDotProd]>;
|
|
|
|
|
def ARMv86a : Architecture<"armv8.6-a", "ARMv86a", [HasV8_6aOps,
|
|
|
|
|
FeatureAClass,
|
|
|
|
|
FeatureDB,
|
|
|
|
|
FeatureFPARMv8,
|
|
|
|
|
FeatureNEON,
|
|
|
|
|
FeatureDSP,
|
|
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureMP,
|
|
|
|
|
FeatureVirtualization,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureRAS,
|
[ARM][AArch64] Armv8.4-A Enablement
Initial patch adding assembly support for Armv8.4-A.
Besides adding v8.4 as a supported architecture to the usual places, this also
adds target features for the different crypto algorithms. Armv8.4-A introduced
new crypto algorithms, made them optional, and allows different combinations:
- none of the v8.4 crypto functions are supported, which is independent of the
implementation of the Armv8.0 SHA1 and SHA2 instructions.
- the v8.4 SHA512 and SHA3 support is implemented, in this case the Armv8.0
SHA1 and SHA2 instructions must also be implemented.
- the v8.4 SM3 and SM4 support is implemented, which is independent of the
implementation of the Armv8.0 SHA1 and SHA2 instructions.
- all of the v8.4 crypto functions are supported, in this case the Armv8.0 SHA1
and SHA2 instructions must also be implemented.
The v8.4 crypto instructions are added to AArch64 only, and not AArch32,
and are made optional extensions to Armv8.2-A.
The user-facing Clang options will map on these new target features, their
naming will be compatible with GCC and added in follow-up patches.
The Armv8.4-A instruction sets can be downloaded here:
https://developer.arm.com/products/architecture/a-profile/exploration-tools
Differential Revision: https://reviews.llvm.org/D48625
llvm-svn: 335953
2018-06-29 16:43:19 +08:00
|
|
|
FeatureDotProd]>;
|
|
|
|
|
|
2016-10-07 20:06:40 +08:00
|
|
|
def ARMv8r : Architecture<"armv8-r", "ARMv8r", [HasV8Ops,
|
|
|
|
|
FeatureRClass,
|
|
|
|
|
FeatureDB,
|
2017-12-21 19:17:49 +08:00
|
|
|
FeatureDFB,
|
2016-10-07 20:06:40 +08:00
|
|
|
FeatureDSP,
|
|
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureMP,
|
|
|
|
|
FeatureVirtualization,
|
|
|
|
|
FeatureFPARMv8,
|
|
|
|
|
FeatureNEON]>;
|
|
|
|
|
|
2016-01-15 18:24:39 +08:00
|
|
|
def ARMv8mBaseline : Architecture<"armv8-m.base", "ARMv8mBaseline",
|
|
|
|
|
[HasV8MBaselineOps,
|
|
|
|
|
FeatureNoARM,
|
[ARM] Remove FeatureNoARM implies ModeThumb.
Summary:
By removing FeatureNoARM implies ModeThumb, we can detect cases where a
function's target-features contain -thumb-mode (enables ARM codegen for the
function), but the architecture does not support ARM mode. Previously, the
implication caused the FeatureNoARM bit to be cleared for functions with
-thumb-mode, making the assertion in ARMSubtarget::ARMSubtarget [1]
pointless for such functions.
This assertion is the only guard against generating ARM code for
architectures without ARM codegen support. Is there a place where we
could easily generate error messages for the user? At the moment, we
would generate ARM code for Thumb-only architectures. X86 has the same
behavior as ARM, as in it only has an assertion and no error message,
but I think for ARM an error message would be helpful. What do you
think?
For the example below, `llc -mtriple=armv7m-eabi test.ll -o -` will
generate ARM assembler (or fail with an assertion error with this patch).
Note that if we run the resulting assembler through llvm-mc, we get
an appropriate error message, but not when codegen is handled
through clang.
```
define void @bar() #0 {
entry:
ret void
}
attributes #0 = { "target-features"="-thumb-mode" }
```
[1] https://github.com/llvm-mirror/llvm/blob/c1f7b54cef62e9c8aa745d40bea146a167bf844e/lib/Target/ARM/ARMSubtarget.cpp#L147
Reviewers: t.p.northover, rengolin, peter.smith, aadg, silviu.baranga, richard.barton.arm, echristo
Reviewed By: rengolin, echristo
Subscribers: efriedma, aemerson, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D35569
llvm-svn: 310476
2017-08-09 21:53:28 +08:00
|
|
|
ModeThumb,
|
2016-01-15 18:24:39 +08:00
|
|
|
FeatureDB,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2016-01-15 18:26:51 +08:00
|
|
|
FeatureV7Clrex,
|
2016-01-25 19:24:47 +08:00
|
|
|
Feature8MSecExt,
|
2016-01-15 18:24:39 +08:00
|
|
|
FeatureAcquireRelease,
|
2018-06-22 18:03:03 +08:00
|
|
|
FeatureMClass,
|
|
|
|
|
FeatureStrictAlign]>;
|
2016-01-15 18:24:39 +08:00
|
|
|
|
|
|
|
|
def ARMv8mMainline : Architecture<"armv8-m.main", "ARMv8mMainline",
|
|
|
|
|
[HasV8MMainlineOps,
|
|
|
|
|
FeatureNoARM,
|
[ARM] Remove FeatureNoARM implies ModeThumb.
Summary:
By removing FeatureNoARM implies ModeThumb, we can detect cases where a
function's target-features contain -thumb-mode (enables ARM codegen for the
function), but the architecture does not support ARM mode. Previously, the
implication caused the FeatureNoARM bit to be cleared for functions with
-thumb-mode, making the assertion in ARMSubtarget::ARMSubtarget [1]
pointless for such functions.
This assertion is the only guard against generating ARM code for
architectures without ARM codegen support. Is there a place where we
could easily generate error messages for the user? At the moment, we
would generate ARM code for Thumb-only architectures. X86 has the same
behavior as ARM, as in it only has an assertion and no error message,
but I think for ARM an error message would be helpful. What do you
think?
For the example below, `llc -mtriple=armv7m-eabi test.ll -o -` will
generate ARM assembler (or fail with an assertion error with this patch).
Note that if we run the resulting assembler through llvm-mc, we get
an appropriate error message, but not when codegen is handled
through clang.
```
define void @bar() #0 {
entry:
ret void
}
attributes #0 = { "target-features"="-thumb-mode" }
```
[1] https://github.com/llvm-mirror/llvm/blob/c1f7b54cef62e9c8aa745d40bea146a167bf844e/lib/Target/ARM/ARMSubtarget.cpp#L147
Reviewers: t.p.northover, rengolin, peter.smith, aadg, silviu.baranga, richard.barton.arm, echristo
Reviewed By: rengolin, echristo
Subscribers: efriedma, aemerson, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D35569
llvm-svn: 310476
2017-08-09 21:53:28 +08:00
|
|
|
ModeThumb,
|
2016-01-15 18:24:39 +08:00
|
|
|
FeatureDB,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2016-01-25 19:24:47 +08:00
|
|
|
Feature8MSecExt,
|
2016-01-15 18:24:39 +08:00
|
|
|
FeatureAcquireRelease,
|
|
|
|
|
FeatureMClass]>;
|
|
|
|
|
|
2019-05-30 20:57:04 +08:00
|
|
|
def ARMv81mMainline : Architecture<"armv8.1-m.main", "ARMv81mMainline",
|
|
|
|
|
[HasV8_1MMainlineOps,
|
|
|
|
|
FeatureNoARM,
|
|
|
|
|
ModeThumb,
|
|
|
|
|
FeatureDB,
|
|
|
|
|
FeatureHWDivThumb,
|
|
|
|
|
Feature8MSecExt,
|
|
|
|
|
FeatureAcquireRelease,
|
|
|
|
|
FeatureMClass,
|
[ARM] Add the non-MVE instructions in Arm v8.1-M.
This adds support for the new family of conditional selection /
increment / negation instructions; the low-overhead branch
instructions (e.g. BF, WLS, DLS); the CLRM instruction to zero a whole
list of registers at once; the new VMRS/VMSR and VLDR/VSTR
instructions to get data in and out of 8.1-M system registers,
particularly including the new VPR register used by MVE vector
predication.
To support this, we also add a register name 'zr' (used by the CSEL
family to force one of the inputs to the constant 0), and operand
types for lists of registers that are also allowed to include APSR or
VPR (used by CLRM). The VLDR/VSTR instructions also need a new
addressing mode.
The low-overhead branch instructions exist in their own separate
architecture extension, which we treat as enabled by default, but you
can say -mattr=-lob or equivalent to turn it off.
Reviewers: dmgreen, samparker, SjoerdMeijer, t.p.northover
Reviewed By: samparker
Subscribers: miyuki, javed.absar, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62667
llvm-svn: 363039
2019-06-11 17:29:18 +08:00
|
|
|
FeatureRAS,
|
|
|
|
|
FeatureLOB]>;
|
2019-05-30 20:57:04 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
// Aliases
|
|
|
|
|
def IWMMXT : Architecture<"iwmmxt", "ARMv5te", [ARMv5te]>;
|
|
|
|
|
def IWMMXT2 : Architecture<"iwmmxt2", "ARMv5te", [ARMv5te]>;
|
|
|
|
|
def XScale : Architecture<"xscale", "ARMv5te", [ARMv5te]>;
|
|
|
|
|
def ARMv6j : Architecture<"armv6j", "ARMv7a", [ARMv6]>;
|
|
|
|
|
def ARMv7k : Architecture<"armv7k", "ARMv7a", [ARMv7a]>;
|
|
|
|
|
def ARMv7s : Architecture<"armv7s", "ARMv7a", [ARMv7a]>;
|
|
|
|
|
|
|
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// ARM schedules.
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
//
|
2019-05-29 21:41:57 +08:00
|
|
|
include "ARMPredicates.td"
|
2017-07-13 18:24:30 +08:00
|
|
|
include "ARMSchedule.td"
|
|
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// ARM processors
|
|
|
|
|
//
|
|
|
|
|
|
|
|
|
|
// Dummy CPU, used to target architectures
|
2017-06-28 15:07:03 +08:00
|
|
|
def : ProcessorModel<"generic", CortexA8Model, []>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
// FIXME: Several processors below are not using their own scheduler
|
|
|
|
|
// model, but one of similar/previous processor. These should be fixed.
|
|
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def : ProcNoItin<"arm8", [ARMv4]>;
|
|
|
|
|
def : ProcNoItin<"arm810", [ARMv4]>;
|
|
|
|
|
def : ProcNoItin<"strongarm", [ARMv4]>;
|
|
|
|
|
def : ProcNoItin<"strongarm110", [ARMv4]>;
|
|
|
|
|
def : ProcNoItin<"strongarm1100", [ARMv4]>;
|
|
|
|
|
def : ProcNoItin<"strongarm1110", [ARMv4]>;
|
|
|
|
|
|
|
|
|
|
def : ProcNoItin<"arm7tdmi", [ARMv4t]>;
|
|
|
|
|
def : ProcNoItin<"arm7tdmi-s", [ARMv4t]>;
|
|
|
|
|
def : ProcNoItin<"arm710t", [ARMv4t]>;
|
|
|
|
|
def : ProcNoItin<"arm720t", [ARMv4t]>;
|
|
|
|
|
def : ProcNoItin<"arm9", [ARMv4t]>;
|
|
|
|
|
def : ProcNoItin<"arm9tdmi", [ARMv4t]>;
|
|
|
|
|
def : ProcNoItin<"arm920", [ARMv4t]>;
|
|
|
|
|
def : ProcNoItin<"arm920t", [ARMv4t]>;
|
|
|
|
|
def : ProcNoItin<"arm922t", [ARMv4t]>;
|
|
|
|
|
def : ProcNoItin<"arm940t", [ARMv4t]>;
|
|
|
|
|
def : ProcNoItin<"ep9312", [ARMv4t]>;
|
|
|
|
|
|
|
|
|
|
def : ProcNoItin<"arm10tdmi", [ARMv5t]>;
|
|
|
|
|
def : ProcNoItin<"arm1020t", [ARMv5t]>;
|
|
|
|
|
|
|
|
|
|
def : ProcNoItin<"arm9e", [ARMv5te]>;
|
|
|
|
|
def : ProcNoItin<"arm926ej-s", [ARMv5te]>;
|
|
|
|
|
def : ProcNoItin<"arm946e-s", [ARMv5te]>;
|
|
|
|
|
def : ProcNoItin<"arm966e-s", [ARMv5te]>;
|
|
|
|
|
def : ProcNoItin<"arm968e-s", [ARMv5te]>;
|
|
|
|
|
def : ProcNoItin<"arm10e", [ARMv5te]>;
|
|
|
|
|
def : ProcNoItin<"arm1020e", [ARMv5te]>;
|
|
|
|
|
def : ProcNoItin<"arm1022e", [ARMv5te]>;
|
|
|
|
|
def : ProcNoItin<"xscale", [ARMv5te]>;
|
|
|
|
|
def : ProcNoItin<"iwmmxt", [ARMv5te]>;
|
|
|
|
|
|
|
|
|
|
def : Processor<"arm1136j-s", ARMV6Itineraries, [ARMv6]>;
|
|
|
|
|
def : Processor<"arm1136jf-s", ARMV6Itineraries, [ARMv6,
|
|
|
|
|
FeatureVFP2,
|
|
|
|
|
FeatureHasSlowFPVMLx]>;
|
|
|
|
|
|
|
|
|
|
def : Processor<"cortex-m0", ARMV6Itineraries, [ARMv6m]>;
|
|
|
|
|
def : Processor<"cortex-m0plus", ARMV6Itineraries, [ARMv6m]>;
|
|
|
|
|
def : Processor<"cortex-m1", ARMV6Itineraries, [ARMv6m]>;
|
|
|
|
|
def : Processor<"sc000", ARMV6Itineraries, [ARMv6m]>;
|
|
|
|
|
|
2017-05-03 03:06:13 +08:00
|
|
|
def : Processor<"arm1176j-s", ARMV6Itineraries, [ARMv6kz]>;
|
2015-11-16 22:05:32 +08:00
|
|
|
def : Processor<"arm1176jz-s", ARMV6Itineraries, [ARMv6kz]>;
|
|
|
|
|
def : Processor<"arm1176jzf-s", ARMV6Itineraries, [ARMv6kz,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureVFP2,
|
|
|
|
|
FeatureHasSlowFPVMLx]>;
|
|
|
|
|
|
|
|
|
|
def : Processor<"mpcorenovfp", ARMV6Itineraries, [ARMv6k]>;
|
|
|
|
|
def : Processor<"mpcore", ARMV6Itineraries, [ARMv6k,
|
|
|
|
|
FeatureVFP2,
|
|
|
|
|
FeatureHasSlowFPVMLx]>;
|
|
|
|
|
|
|
|
|
|
def : Processor<"arm1156t2-s", ARMV6Itineraries, [ARMv6t2]>;
|
|
|
|
|
def : Processor<"arm1156t2f-s", ARMV6Itineraries, [ARMv6t2,
|
|
|
|
|
FeatureVFP2,
|
|
|
|
|
FeatureHasSlowFPVMLx]>;
|
2009-05-30 07:41:08 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def : ProcessorModel<"cortex-a5", CortexA8Model, [ARMv7a, ProcA5,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureSlowFPBrcc,
|
|
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureVMLxForwarding,
|
|
|
|
|
FeatureMP,
|
|
|
|
|
FeatureVFP4]>;
|
|
|
|
|
|
|
|
|
|
def : ProcessorModel<"cortex-a7", CortexA8Model, [ARMv7a, ProcA7,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureSlowFPBrcc,
|
2016-07-07 17:11:39 +08:00
|
|
|
FeatureHasVMLxHazards,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureVMLxForwarding,
|
|
|
|
|
FeatureMP,
|
|
|
|
|
FeatureVFP4,
|
|
|
|
|
FeatureVirtualization]>;
|
|
|
|
|
|
|
|
|
|
def : ProcessorModel<"cortex-a8", CortexA8Model, [ARMv7a, ProcA8,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2016-06-27 17:08:23 +08:00
|
|
|
FeatureNonpipelinedVFP,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureSlowFPBrcc,
|
2016-07-07 17:11:39 +08:00
|
|
|
FeatureHasVMLxHazards,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
2016-07-20 03:49:13 +08:00
|
|
|
FeatureVMLxForwarding]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
|
|
|
|
def : ProcessorModel<"cortex-a9", CortexA9Model, [ARMv7a, ProcA9,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureTrustZone,
|
2016-07-07 17:11:39 +08:00
|
|
|
FeatureHasVMLxHazards,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureVMLxForwarding,
|
|
|
|
|
FeatureFP16,
|
|
|
|
|
FeatureAvoidPartialCPSR,
|
2016-07-07 17:11:39 +08:00
|
|
|
FeatureExpandMLx,
|
2016-06-23 15:47:35 +08:00
|
|
|
FeaturePreferVMOVSR,
|
2016-07-06 17:22:23 +08:00
|
|
|
FeatureMuxedUnits,
|
2016-06-23 15:47:35 +08:00
|
|
|
FeatureNEONForFPMovs,
|
2016-06-27 17:08:23 +08:00
|
|
|
FeatureCheckVLDnAlign,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureMP]>;
|
2013-11-22 19:53:16 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def : ProcessorModel<"cortex-a12", CortexA9Model, [ARMv7a, ProcA12,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureVMLxForwarding,
|
|
|
|
|
FeatureVFP4,
|
|
|
|
|
FeatureAvoidPartialCPSR,
|
|
|
|
|
FeatureVirtualization,
|
|
|
|
|
FeatureMP]>;
|
|
|
|
|
|
|
|
|
|
def : ProcessorModel<"cortex-a15", CortexA9Model, [ARMv7a, ProcA15,
|
2016-07-06 19:22:11 +08:00
|
|
|
FeatureDontWidenVMOVS,
|
2018-07-21 00:49:28 +08:00
|
|
|
FeatureSplatVFPToNeon,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2016-07-06 17:22:23 +08:00
|
|
|
FeatureMuxedUnits,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureVFP4,
|
|
|
|
|
FeatureMP,
|
2016-06-27 17:08:23 +08:00
|
|
|
FeatureCheckVLDnAlign,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureAvoidPartialCPSR,
|
|
|
|
|
FeatureVirtualization]>;
|
2013-11-22 19:53:16 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def : ProcessorModel<"cortex-a17", CortexA9Model, [ARMv7a, ProcA17,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureTrustZone,
|
|
|
|
|
FeatureMP,
|
|
|
|
|
FeatureVMLxForwarding,
|
|
|
|
|
FeatureVFP4,
|
|
|
|
|
FeatureAvoidPartialCPSR,
|
|
|
|
|
FeatureVirtualization]>;
|
2014-10-13 18:22:19 +08:00
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
// FIXME: krait has currently the same features as A9 plus VFP4 and HWDiv
|
2015-11-16 19:10:19 +08:00
|
|
|
def : ProcessorModel<"krait", CortexA9Model, [ARMv7a, ProcKrait,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2016-07-06 17:22:23 +08:00
|
|
|
FeatureMuxedUnits,
|
2016-06-27 17:08:23 +08:00
|
|
|
FeatureCheckVLDnAlign,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureVMLxForwarding,
|
|
|
|
|
FeatureFP16,
|
|
|
|
|
FeatureAvoidPartialCPSR,
|
|
|
|
|
FeatureVFP4,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureHWDivARM]>;
|
|
|
|
|
|
|
|
|
|
def : ProcessorModel<"swift", SwiftModel, [ARMv7a, ProcSwift,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureNEONForFP,
|
|
|
|
|
FeatureVFP4,
|
2018-08-10 00:13:24 +08:00
|
|
|
FeatureUseWideStrideVFP,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureMP,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureAvoidPartialCPSR,
|
|
|
|
|
FeatureAvoidMOVsShOp,
|
2016-06-23 15:47:35 +08:00
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
2016-07-07 17:11:39 +08:00
|
|
|
FeatureHasVMLxHazards,
|
2016-06-23 15:47:35 +08:00
|
|
|
FeatureProfUnpredicate,
|
|
|
|
|
FeaturePrefISHSTBarrier,
|
2016-07-06 17:22:23 +08:00
|
|
|
FeatureSlowOddRegister,
|
|
|
|
|
FeatureSlowLoadDSubreg,
|
2016-06-23 15:47:35 +08:00
|
|
|
FeatureSlowVGETLNi32,
|
2017-07-28 03:56:44 +08:00
|
|
|
FeatureSlowVDUP32,
|
2017-08-31 16:57:51 +08:00
|
|
|
FeatureUseMISched,
|
|
|
|
|
FeatureNoPostRASched]>;
|
2014-04-01 21:22:02 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def : ProcessorModel<"cortex-r4", CortexA8Model, [ARMv7r, ProcR4,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2016-07-20 03:49:13 +08:00
|
|
|
FeatureAvoidPartialCPSR]>;
|
2015-04-09 22:07:28 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def : ProcessorModel<"cortex-r4f", CortexA8Model, [ARMv7r, ProcR4,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureSlowFPBrcc,
|
|
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
FeatureVFP3_D16,
|
2016-07-20 03:49:13 +08:00
|
|
|
FeatureAvoidPartialCPSR]>;
|
2015-04-09 22:07:28 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def : ProcessorModel<"cortex-r5", CortexA8Model, [ARMv7r, ProcR5,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
FeatureVFP3_D16,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureSlowFPBrcc,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
2016-07-20 03:49:13 +08:00
|
|
|
FeatureAvoidPartialCPSR]>;
|
2010-08-11 14:30:38 +08:00
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def : ProcessorModel<"cortex-r7", CortexA8Model, [ARMv7r, ProcR7,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
FeatureVFP3_D16,
|
2015-12-07 18:54:36 +08:00
|
|
|
FeatureFP16,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureMP,
|
|
|
|
|
FeatureSlowFPBrcc,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
2016-07-20 03:49:13 +08:00
|
|
|
FeatureAvoidPartialCPSR]>;
|
2016-03-11 01:38:41 +08:00
|
|
|
|
|
|
|
|
def : ProcessorModel<"cortex-r8", CortexA8Model, [ARMv7r,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
FeatureVFP3_D16,
|
2016-03-11 01:38:41 +08:00
|
|
|
FeatureFP16,
|
|
|
|
|
FeatureMP,
|
|
|
|
|
FeatureSlowFPBrcc,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
2016-07-20 03:49:13 +08:00
|
|
|
FeatureAvoidPartialCPSR]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
2019-05-15 20:41:58 +08:00
|
|
|
def : ProcessorModel<"cortex-m3", CortexM4Model, [ARMv7m,
|
2017-06-28 22:11:15 +08:00
|
|
|
ProcM3,
|
2018-09-13 18:28:05 +08:00
|
|
|
FeaturePrefLoopAlign32,
|
2019-05-15 20:41:58 +08:00
|
|
|
FeatureUseMISched,
|
2017-08-31 16:57:51 +08:00
|
|
|
FeatureHasNoBranchPredictor]>;
|
2017-06-28 22:11:15 +08:00
|
|
|
|
2019-05-15 20:41:58 +08:00
|
|
|
def : ProcessorModel<"sc300", CortexM4Model, [ARMv7m,
|
2017-06-28 22:11:15 +08:00
|
|
|
ProcM3,
|
2019-05-15 20:41:58 +08:00
|
|
|
FeatureUseMISched,
|
2017-06-28 22:11:15 +08:00
|
|
|
FeatureHasNoBranchPredictor]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
def : ProcessorModel<"cortex-m4", CortexM4Model, [ARMv7em,
|
|
|
|
|
FeatureVFP4_D16_SP,
|
2018-09-13 18:28:05 +08:00
|
|
|
FeaturePrefLoopAlign32,
|
2018-09-24 20:02:50 +08:00
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
2019-05-15 20:41:58 +08:00
|
|
|
FeatureUseMISched,
|
2017-08-31 16:57:51 +08:00
|
|
|
FeatureHasNoBranchPredictor]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
|
|
|
|
def : ProcNoItin<"cortex-m7", [ARMv7em,
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
FeatureFPARMv8_D16]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
2017-02-01 19:55:03 +08:00
|
|
|
def : ProcNoItin<"cortex-m23", [ARMv8mBaseline,
|
|
|
|
|
FeatureNoMovt]>;
|
|
|
|
|
|
2019-05-15 20:41:58 +08:00
|
|
|
def : ProcessorModel<"cortex-m33", CortexM4Model, [ARMv8mMainline,
|
2017-02-01 19:55:03 +08:00
|
|
|
FeatureDSP,
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
FeatureFPARMv8_D16_SP,
|
2018-09-13 18:28:05 +08:00
|
|
|
FeaturePrefLoopAlign32,
|
2018-09-24 20:02:50 +08:00
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
2019-05-15 20:41:58 +08:00
|
|
|
FeatureUseMISched,
|
2017-08-31 16:57:51 +08:00
|
|
|
FeatureHasNoBranchPredictor]>;
|
2017-02-01 19:55:03 +08:00
|
|
|
|
2019-05-15 20:41:58 +08:00
|
|
|
def : ProcessorModel<"cortex-m35p", CortexM4Model, [ARMv8mMainline,
|
2019-02-26 20:02:12 +08:00
|
|
|
FeatureDSP,
|
[ARM] Replace fp-only-sp and d16 with fp64 and d32.
Those two subtarget features were awkward because their semantics are
reversed: each one indicates the _lack_ of support for something in
the architecture, rather than the presence. As a consequence, you
don't get the behavior you want if you combine two sets of feature
bits.
Each SubtargetFeature for an FP architecture version now comes in four
versions, one for each combination of those options. So you can still
say (for example) '+vfp2' in a feature string and it will mean what
it's always meant, but there's a new string '+vfp2d16sp' meaning the
version without those extra options.
A lot of this change is just mechanically replacing positive checks
for the old features with negative checks for the new ones. But one
more interesting change is that I've rearranged getFPUFeatures() so
that the main FPU feature is appended to the output list *before*
rather than after the features derived from the Restriction field, so
that -fp64 and -d32 can override defaults added by the main feature.
Reviewers: dmgreen, samparker, SjoerdMeijer
Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D60691
llvm-svn: 361845
2019-05-29 00:13:20 +08:00
|
|
|
FeatureFPARMv8_D16_SP,
|
2019-02-26 20:02:12 +08:00
|
|
|
FeaturePrefLoopAlign32,
|
|
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
2019-05-15 20:41:58 +08:00
|
|
|
FeatureUseMISched,
|
2019-02-26 20:02:12 +08:00
|
|
|
FeatureHasNoBranchPredictor]>;
|
|
|
|
|
|
2020-02-14 21:33:32 +08:00
|
|
|
def : ProcessorModel<"cortex-m55", CortexM4Model, [ARMv81mMainline,
|
|
|
|
|
FeatureDSP,
|
|
|
|
|
FeatureFPARMv8_D16,
|
|
|
|
|
FeatureUseMISched,
|
|
|
|
|
FeatureHasNoBranchPredictor,
|
|
|
|
|
FeaturePrefLoopAlign32,
|
|
|
|
|
FeatureHasSlowFPVMLx,
|
|
|
|
|
HasMVEFloatOps]>;
|
2019-02-26 20:02:12 +08:00
|
|
|
|
2016-03-22 01:29:01 +08:00
|
|
|
def : ProcNoItin<"cortex-a32", [ARMv8a,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2016-03-22 01:29:01 +08:00
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
2015-12-02 19:53:44 +08:00
|
|
|
def : ProcNoItin<"cortex-a35", [ARMv8a, ProcA35,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2015-12-02 19:53:44 +08:00
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC]>;
|
|
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def : ProcNoItin<"cortex-a53", [ARMv8a, ProcA53,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
2016-10-13 22:57:43 +08:00
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureFPAO]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
2017-08-21 16:43:06 +08:00
|
|
|
def : ProcNoItin<"cortex-a55", [ARMv82a, ProcA55,
|
|
|
|
|
FeatureHWDivThumb,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureDotProd]>;
|
|
|
|
|
|
2017-07-13 18:24:30 +08:00
|
|
|
def : ProcessorModel<"cortex-a57", CortexA57Model, [ARMv8a, ProcA57,
|
|
|
|
|
FeatureHWDivThumb,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureFPAO,
|
|
|
|
|
FeatureAvoidPartialCPSR,
|
|
|
|
|
FeatureCheapPredicableCPSR]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
2018-10-25 23:08:29 +08:00
|
|
|
def : ProcessorModel<"cortex-a72", CortexA57Model, [ARMv8a, ProcA72,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC]>;
|
2013-06-27 00:58:26 +08:00
|
|
|
|
2016-06-02 18:48:52 +08:00
|
|
|
def : ProcNoItin<"cortex-a73", [ARMv8a, ProcA73,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2016-06-02 18:48:52 +08:00
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC]>;
|
|
|
|
|
|
2017-08-21 16:43:06 +08:00
|
|
|
def : ProcNoItin<"cortex-a75", [ARMv82a, ProcA75,
|
|
|
|
|
FeatureHWDivThumb,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureDotProd]>;
|
|
|
|
|
|
2019-02-25 23:08:27 +08:00
|
|
|
def : ProcNoItin<"cortex-a76", [ARMv82a, ProcA76,
|
|
|
|
|
FeatureHWDivThumb,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureFullFP16,
|
|
|
|
|
FeatureDotProd]>;
|
|
|
|
|
|
|
|
|
|
def : ProcNoItin<"cortex-a76ae", [ARMv82a, ProcA76,
|
|
|
|
|
FeatureHWDivThumb,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureFullFP16,
|
|
|
|
|
FeatureDotProd]>;
|
[ARM] Add Cortex-A77 Support for Clang and LLVM
This patch upstreams support for the Arm-v8 Cortex-A77
processor for AArch64 and ARM.
In detail:
- Adding cortex-a77 as a cpu option for aarch64 and arm targets in clang
- Cortex-A77 CPU name and ProcessorModel in llvm
details of the CPU can be found here:
https://www.arm.com/products/silicon-ip-cpu/cortex-a/cortex-a77
and a similar submission to GCC can be found here:
https://github.com/gcc-mirror/gcc/commit/e0664b7a63ed8305e9f8539309df7fb3eb13babe
The following people contributed to this patch:
- Luke Geeson
- Mikhail Maltsev
Reviewers: t.p.northover, dmgreen, ostannard, SjoerdMeijer
Reviewed By: dmgreen
Subscribers: dmgreen, kristof.beyls, hiraditya, danielkiss, cfe-commits,
llvm-commits, miyuki
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D82887
2020-06-30 23:45:36 +08:00
|
|
|
|
|
|
|
|
def : ProcNoItin<"cortex-a77", [ARMv82a, ProcA77,
|
|
|
|
|
FeatureHWDivThumb,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureFullFP16,
|
|
|
|
|
FeatureDotProd]>;
|
2020-07-01 19:50:36 +08:00
|
|
|
|
|
|
|
|
def : ProcNoItin<"cortex-a78", [ARMv82a, ProcA78,
|
|
|
|
|
FeatureHWDivThumb,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureFullFP16,
|
|
|
|
|
FeatureDotProd]>;
|
|
|
|
|
|
|
|
|
|
def : ProcNoItin<"cortex-x1", [ARMv82a, ProcX1,
|
|
|
|
|
FeatureHWDivThumb,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureFullFP16,
|
|
|
|
|
FeatureDotProd]>;
|
2019-02-25 23:08:27 +08:00
|
|
|
|
[ARM][AArch64] Support for Cortex-A65 & A65AE, Neoverse E1 & N1
Summary:
Add support for Cortex-A65, Cortex-A65AE, Neoverse E1 and Neoverse N1.
Neoverse E1 and Cortex-A65(&AE) only implement the AArch64 state of the
Arm architecture. Neoverse N1 implements both AArch32 and AArch64.
Cortex-A65:
https://developer.arm.com/ip-products/processors/cortex-a/cortex-a65
Cortex-A65AE:
https://developer.arm.com/ip-products/processors/cortex-a/cortex-a65ae
Neoverse E1:
https://developer.arm.com/ip-products/processors/neoverse/neoverse-e1
Neoverse N1:
https://developer.arm.com/ip-products/processors/neoverse/neoverse-n1
Patch by Diogo Sampaio and Pablo Barrio
Reviewers: samparker, LukeCheeseman, sbaranga, ostannard
Reviewed By: ostannard
Subscribers: ostannard, javed.absar, kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64406
llvm-svn: 367007
2019-07-25 18:59:45 +08:00
|
|
|
def : ProcNoItin<"neoverse-n1", [ARMv82a,
|
|
|
|
|
FeatureHWDivThumb,
|
|
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC,
|
|
|
|
|
FeatureDotProd]>;
|
|
|
|
|
|
2015-11-16 19:10:19 +08:00
|
|
|
def : ProcessorModel<"cyclone", SwiftModel, [ARMv8a, ProcSwift,
|
2016-06-03 22:03:27 +08:00
|
|
|
FeatureHasRetAddrStack,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureNEONForFP,
|
|
|
|
|
FeatureVFP4,
|
|
|
|
|
FeatureMP,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureAvoidPartialCPSR,
|
|
|
|
|
FeatureAvoidMOVsShOp,
|
|
|
|
|
FeatureHasSlowFPVMLx,
|
2020-01-05 18:59:21 +08:00
|
|
|
FeatureHasSlowFPVFMx,
|
2015-11-16 19:10:19 +08:00
|
|
|
FeatureCrypto,
|
2017-07-28 03:56:44 +08:00
|
|
|
FeatureUseMISched,
|
2017-08-31 16:57:51 +08:00
|
|
|
FeatureZCZeroing,
|
|
|
|
|
FeatureNoPostRASched]>;
|
2015-11-16 19:10:19 +08:00
|
|
|
|
2018-09-20 03:43:23 +08:00
|
|
|
def : ProcNoItin<"exynos-m3", [ARMv8a, ProcExynos]>;
|
2019-01-12 02:54:25 +08:00
|
|
|
def : ProcNoItin<"exynos-m4", [ARMv82a, ProcExynos,
|
|
|
|
|
FeatureFullFP16,
|
|
|
|
|
FeatureDotProd]>;
|
2019-03-23 02:42:14 +08:00
|
|
|
def : ProcNoItin<"exynos-m5", [ARMv82a, ProcExynos,
|
|
|
|
|
FeatureFullFP16,
|
|
|
|
|
FeatureDotProd]>;
|
2016-12-14 07:31:41 +08:00
|
|
|
|
2017-04-07 06:47:47 +08:00
|
|
|
def : ProcNoItin<"kryo", [ARMv8a, ProcKryo,
|
2017-04-20 17:38:25 +08:00
|
|
|
FeatureHWDivThumb,
|
2017-04-07 06:47:47 +08:00
|
|
|
FeatureHWDivARM,
|
|
|
|
|
FeatureCrypto,
|
|
|
|
|
FeatureCRC]>;
|
|
|
|
|
|
2016-11-15 19:34:54 +08:00
|
|
|
def : ProcessorModel<"cortex-r52", CortexR52Model, [ARMv8r, ProcR52,
|
2018-04-27 19:29:49 +08:00
|
|
|
FeatureUseMISched,
|
2019-11-05 18:46:56 +08:00
|
|
|
FeatureFPAO]>;
|
2016-10-07 20:06:40 +08:00
|
|
|
|
2006-05-15 06:18:28 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// Register File Description
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
include "ARMRegisterInfo.td"
|
2017-02-05 20:07:55 +08:00
|
|
|
include "ARMRegisterBanks.td"
|
2009-04-18 03:07:39 +08:00
|
|
|
include "ARMCallingConv.td"
|
|
|
|
|
|
2006-05-15 06:18:28 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// Instruction Descriptions
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
include "ARMInstrInfo.td"
|
2010-04-05 11:10:20 +08:00
|
|
|
def ARMInstrInfo : InstrInfo;
|
2006-05-15 06:18:28 +08:00
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// Declare the target which we are implementing
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2015-03-28 07:41:42 +08:00
|
|
|
def ARMAsmWriter : AsmWriter {
|
|
|
|
|
string AsmWriterClassName = "InstPrinter";
|
|
|
|
|
int PassSubtarget = 1;
|
|
|
|
|
int Variant = 0;
|
|
|
|
|
bit isMCAsmWriter = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2017-10-03 18:26:11 +08:00
|
|
|
def ARMAsmParser : AsmParser {
|
|
|
|
|
bit ReportMultipleNearMisses = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-09 08:31:07 +08:00
|
|
|
def ARMAsmParserVariant : AsmParserVariant {
|
|
|
|
|
int Variant = 0;
|
|
|
|
|
string Name = "ARM";
|
|
|
|
|
string BreakCharacters = ".";
|
|
|
|
|
}
|
|
|
|
|
|
2006-05-15 06:18:28 +08:00
|
|
|
def ARM : Target {
|
2017-07-13 18:24:30 +08:00
|
|
|
// Pull in Instruction Info.
|
2006-05-15 06:18:28 +08:00
|
|
|
let InstructionSet = ARMInstrInfo;
|
2015-03-28 07:41:42 +08:00
|
|
|
let AssemblyWriters = [ARMAsmWriter];
|
2017-10-03 18:26:11 +08:00
|
|
|
let AssemblyParsers = [ARMAsmParser];
|
2015-11-09 08:31:07 +08:00
|
|
|
let AssemblyParserVariants = [ARMAsmParserVariant];
|
[MachineOperand][Target] MachineOperand::isRenamable semantics changes
Summary:
Add a target option AllowRegisterRenaming that is used to opt in to
post-register-allocation renaming of registers. This is set to 0 by
default, which causes the hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq
fields of all opcodes to be set to 1, causing
MachineOperand::isRenamable to always return false.
Set the AllowRegisterRenaming flag to 1 for all in-tree targets that
have lit tests that were effected by enabling COPY forwarding in
MachineCopyPropagation (AArch64, AMDGPU, ARM, Hexagon, Mips, PowerPC,
RISCV, Sparc, SystemZ and X86).
Add some more comments describing the semantics of the
MachineOperand::isRenamable function and how it is set and maintained.
Change isRenamable to check the operand's opcode
hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq bit directly instead of
relying on it being consistently reflected in the IsRenamable bit
setting.
Clear the IsRenamable bit when changing an operand's register value.
Remove target code that was clearing the IsRenamable bit when changing
registers/opcodes now that this is done conservatively by default.
Change setting of hasExtraSrcRegAllocReq in AMDGPU target to be done in
one place covering all opcodes that have constant pipe read limit
restrictions.
Reviewers: qcolombet, MatzeB
Subscribers: aemerson, arsenm, jyknight, mcrosier, sdardis, nhaehnle, javed.absar, tpr, arichardson, kristof.beyls, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, niosHD, escha, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D43042
llvm-svn: 325931
2018-02-24 02:25:08 +08:00
|
|
|
let AllowRegisterRenaming = 1;
|
2006-05-15 06:18:28 +08:00
|
|
|
}
|