Arch extensions and default target features in TargetParser

[labrinea]

Summary

• Added arch extensions in TargetParser
• Added API for retrieving the corresponding target features
• To be tested by clang

[labrinea]

lib/Support/TargetParser.cpp

181

Changed to

if (StringRef("idiv") == AE.Name)

due to compiler warning

[richard.barton.arm]

Alexandros asked if I could look over the table of extensions, but I have some points on the code in general.

I have a few concerns about the direction we are taking here which can be summarised as:

• Do we care about GCC compatibility?
• Do we care about close adherence to ARM terminology?

For the first, I note that we are thinking of supporting the -march/mcpu=arch/cpu+{no}extn syntax for the AArch32 driver. This is great news and gcc trunk is going the same way. However, gcc are only doing this for integer extensions, and currently only "+crc" is supported here. I have not got confirmation from them whether they intend to go back and do this for pre-ARMv8 extensions, so I don't know if "+hwdivarm" or equivalent is intended to be added for example. The presence of "+fp" in this list concerns me for two reasons. Firstly, ARMv7-A and ARMv7-M have two legal FP extensions - VFPv3 or VFPv4 and VFPv4 or FPv5 respectively - so which of these does "+fp" mean when targeting one of these architectures. Secondly, from talking to the GCC guys here at ARM, they are adamant that they will not be supporting floating point extensions in the -march=arch+extn syntax mostly for legacy reasons.

With this change we are intentionally allowing more than what GCC will allow for these options. I don't think that is a problem per-se, but thought that it was worth pointing out so we are all sure we know what we are doing. I wonder whether the extension table should have a field saying which frontend (AArch64 vs ARM) each extension is permitted in as an -march=arch+extn option?

Secondly, our implementation does not adhere to the letter of the ARMARM with respect to architectural extensions. For example, "hwdiv" (as in SDIV/UDIV in T32 mode) is never an architectural extension. "hwdiv" is part of the base ARMv7-R, ARMv7-(E)M and ARMv8-A. The Division extension is an optional extension to both ARMv7-A and ARMv7-R and mandates SDIV/UDIV in both instruction sets. Therefore, "hwdiv" - i.e. T32 divide by itself, is never allowed as an architectural extension. It is either part of the base architecture or as part of the division extension alongside "hwdiv" - i.e. A32 Divide by itself. Thus a better extension would be something like "+div" which would add divide to both instruction sets were it not already present. Note also, that we would not be compatible with GCC on this option.

Again - this is not a deal breaker and the net result in terms of which instructions are available is the same. I just wanted to raise this as a concern so that we are all on the same page.

Regarding the table, apart from the above Divide concern, I notice also

• the lack of MP extension for Cortex-R5, Cortex-R7, Cortex-A5, Cortex-A7, Cortex-A9, Cortex-A12, Cortex-A15 and Cortex-A17.
• the lack of Virtualization extension for Cortex-A7, Cortex-A12, Cortex-A15 and Cortex-A17.
• the OS extension is the difference between ARMv6-M and ARMv6S-M (although I understand that ARMv6-M in clang/llvm really means ARMv6S-M, which is fine) and does not get used anywhere.
• XScale and iwmmxt being available as both architectures and extensions. Not sure if that is correct or not.

[rengolin]

In D11590#215067, @richard.barton.arm wrote:

I have a few concerns about the direction we are taking here which can be summarised as:

• Do we care about GCC compatibility?

To a point. We don't want to do things differently, but it should be ok to do more, or to do less, in certain cases.

• Do we care about close adherence to ARM terminology?

When there is no legacy concerns, yes.

With this change we are intentionally allowing more than what GCC will allow for these options. I don't think that is a problem per-se, but thought that it was worth pointing out so we are all sure we know what we are doing. I wonder whether the extension table should have a field saying which frontend (AArch64 vs ARM) each extension is permitted in as an -march=arch+extn option?

Since the parser is universal, and we can support those features by adding/removing them from the target description, I see no reason to *not* have them. We'd have to *add* code to have *less* functionality. Since this is in the area where we're doing more, not different, it should be ok.

Secondly, our implementation does not adhere to the letter of the ARMARM with respect to architectural extensions. For example, "hwdiv" (as in SDIV/UDIV in T32 mode) is never an architectural extension. "hwdiv" is part of the base ARMv7-R, ARMv7-(E)M and ARMv8-A. The Division extension is an optional extension to both ARMv7-A and ARMv7-R and mandates SDIV/UDIV in both instruction sets. Therefore, "hwdiv" - i.e. T32 divide by itself, is never allowed as an architectural extension. It is either part of the base architecture or as part of the division extension alongside "hwdiv" - i.e. A32 Divide by itself. Thus a better extension would be something like "+div" which would add divide to both instruction sets were it not already present. Note also, that we would not be compatible with GCC on this option.

This is not easy to solve. We're coming from GNU-land, where the options in the assembler and command-line options already existed, and we *have* to support them. For new options, we should adhere to the ARM ARM, but for legacy ones, we need to keep compatible.

Regarding HWdiv, there is a catch. For instance, Krait has HWdiv, but it's closer to an A9 than an A15. We've added a patch that teaches that to LLVM, so if we can't have HWdiv as an extension, that won't work, and we'll produce worse code for Krait. Not to mention the legacy ".arch_extension idiv" options that we have to support.

Furthermore, HWdiv in the ARM ARM is separated between SDIV and UDIV, but what we really model is ARMDIIV and T2DIV, which is orthogonal and not clearly represented in any ARM document (since those things are optional, like Krait).

If anything, to help both your points, I'd add an extra flag to say if these options are accepted as arguments/directives or not. So, internally, to find the flags, you'd pass "true" to the option of finding any, and front-ends/tools would pass "false", to only get what's parseable.

cheers,
--renato

[richard.barton.arm]

Thanks for explaining the Krait situation - this now makes sense to me and I agree that it is not ideal.

If anything, to help both your points, I'd add an extra flag to say if these options are accepted as arguments/directives or not. So, internally, to find the flags, you'd pass "true" to the option of finding any, and front-ends/tools would pass "false", to only get what's parseable.

This seems like a good idea to me. That way we can control what is available from which direction. I think that the AArch32 +fp case for ARMv7 should be reason enough for us to want to do this. Saying -march=armv7-a+fp cannot give a sensible result, so restricting the available extns per backend is sensible.

Do we intend to resolve my other points regarding MP, Virtiualization (and to a lesser extent OS) in this patch?

[rengolin]

In D11590#215075, @richard.barton.arm wrote:

This seems like a good idea to me. That way we can control what is available from which direction. I think that the AArch32 +fp case for ARMv7 should be reason enough for us to want to do this. Saying -march=armv7-a+fp cannot give a sensible result, so restricting the available extns per backend is sensible.

With just two variants for the foreseeable future (A32/A64), I think it should be ok to have two flags.

Do we intend to resolve my other points regarding MP, Virtiualization (and to a lesser extent OS) in this patch?

Yes. Anything that deviates from either GCC/Darwin legacy or the ARM ARM must have an explicit and reasonable explanation.

I'd welcome more ARM folks having a thorough look at this, as you guys have a larger collective memory about these things. :)

[richard.barton.arm]

Agreed - I can look at the next revision from Alexandros regarding adding MP and Virtualization to this table (I am less fussed about OS)

I am not sure I can review effectively the infrastructure part of limiting the extensions per frontend, but once that is in place, I am happy to review a new version of the arch extension table. I am also not clear whether that additional work should be part of this patch or can come later. Renato - what do you think?

[rengolin]

In D11590#215088, @richard.barton.arm wrote:

Agreed - I can look at the next revision from Alexandros regarding adding MP and Virtualization to this table (I am less fussed about OS)

Thanks!

I am not sure I can review effectively the infrastructure part of limiting the extensions per frontend, but once that is in place, I am happy to review a new version of the arch extension table. I am also not clear whether that additional work should be part of this patch or can come later. Renato - what do you think?

I think the best option would be to get the table correct with the current values, then extend it to a better model later.

[labrinea]

Am I right that ARM::AEK_SIMD means NEON extension and not SIMD32 instructions?

[labrinea]

• added more arch extensions
• separated hwdiv from default extensions in arm v7r, v7(e)m, v8a

[richard.barton.arm]

Comments inline.

lib/Support/TargetParser.cpp

129

And this one is here because we want -mcpu=cortex-m4 to select Cortex-M4F rather than Cortex-M4? Why do we want that? Wouldn't we want it to match Cortex-R4?

176

Shouldn't this be "cortex-r5f" with another line for "cortex-r5" with no FP?

Also, the Cortex-R5F FP unit is SP only.

[richard.barton.arm]

lib/Support/TargetParser.cpp

84

IIUC - this field indicates whether the ARCHExtNames should be passed on as-is to the LLVM backend. Surely all of these flags should end up going to the backend somehow or another or I would not be enabling the backend features correctly? In this case, wouldn't a better field be a

const char *backend_name

?

Apologies if I have misunderstood what is happening here.

98

I have now twigged what this is: Trustzone/Security Extensions.

This is part of the base ARMv6Z architecture. Assuming we want to make the name context sensitive (which I think is a good idea) then there is a security extension as an optional extension on the ARMv7-A architecture profile and then becomes a base part of the ARMv8-A architecture.

All of the ARMv7 Cortex-A* cores implement the security extensions.

120

IIUC - all the entries here are intentional duplicates that are incorrect?

149

I don't know exactly how this all fits together, but should this not take the IWMMXT architecture extension mentioned in the above list?

150

Again - there is an architectural extension for XSCALE which should presumably go here (although I don't know what you want it to do)

154

This should be an ARMv6Z core. ARMv6Z is ARMv6 + Security extensions.

157

This entry duplicates the two below it. This entry gets it wrong, so should go, the ARMv6SZ one is correct.

159

Bin

[rengolin]

lib/Support/TargetParser.cpp

84

No, this is the "is it available to the parser" or not. As we discussed, this should be at least split into arm32 and arm64 flags.

98

This is a legacy option from GCC, I believe. What it is now is what it was before (no one has changed it), so I wouldn't try to be smart here, at least not unless we understand the stakes.

120

these are just here to return the correct default CPU for the "unsupported" architecture IDs.

With the other patch to use "generic" instead, this will be deprecated. Just let is stay for now.

159

No, this is needed (sorry, it's a mess) to correctly identify that ARMv6ZK has a default CPU...

176

possibly two lines, one for each. I guess we spoke about this before, but had no harder evidence that it was beneficial. Now, with the default options, it makes a clear cut to having both.

[richard.barton.arm]

lib/Support/TargetParser.cpp

84

OK - so a better name would do it then - CmdLineOptionAArch32, with CmdLineOptionAArch64 to follow once we hook the frontend into all this.

98

Binutils docs confirm my interpretation: https://sourceware.org/binutils/docs/as/ARM-Options.html#ARM-Options

159

In that case - should we move it to the "unsupported" section like the other bogus mappings?

[labrinea]

lib/Support/TargetParser.cpp

129

This looks like a typo of the previous patch.

170

I added this function to distinguish base arch features from arch extension. Having more base features than just hwdiv (ex. security extensions, etc... as Richard mentioned to a previous comment) it would make sense to me either to create a new column to CPUNames table indicating base features (but the values will be ARM::AEK_* which is confusing) or add the base features to the existing column of DefaultExtensions. Let me know your thoughts on this.

176

I suggested this in a previous patch, however there is no logic for r5f in ARM.td or anywhere else I think. I also think r5f fpu is FK_VFPV3_D16. Let's double check.

283

IsBackendOption is used here to decide whether to forward the features to ARMTargetInfo or not (if the backend does not recognize the features we have warnings and regressions).

[labrinea]

lib/Support/TargetParser.cpp

170

*I guess the new column fits best in ARCHNames table rather than CPUNames table.

[labrinea]

In D11590#215067, @richard.barton.arm wrote:

Regarding the table, apart from the above Divide concern, I notice also

• the lack of MP extension for Cortex-R5

Are we sure Cortex-R5 has MP extensions?

[richard.barton.arm]

In D11590#215878, @labrinea wrote:

In D11590#215067, @richard.barton.arm wrote:

Regarding the table, apart from the above Divide concern, I notice also

• the lack of MP extension for Cortex-R5

Are we sure Cortex-R5 has MP extensions?

r0 versions of Cortex-R5 did not have MP extensions. r1 versions do have the MP extensions. My understanding is that clang likes to target the latest revision for cores. If that understanding is correct, then it should have MP extensions.

lib/Support/TargetParser.cpp

283

Sure - my point is that surely clang needs to forward all relevant extensions to the backend so it is set up correctly. So rather than only sending those with exactly the right name, surely a backend name field would be best so that all features could be sent to the backend?

I am backseat driving here, so if this some other way that backend features get enabled, then feel free to ignore me.

[richard.barton.arm]

lib/Support/TargetParser.cpp

176

If that is the case, then I am happy that it is outside the scope of your patch and can be left for another time.

[rengolin]

In D11590#215880, @richard.barton.arm wrote:

r0 versions of Cortex-R5 did not have MP extensions. r1 versions do have the MP extensions. My understanding is that clang likes to target the latest revision for cores. If that understanding is correct, then it should have MP extensions.

We tend to pick the most common, or what users expect they will see, not the latest.

People expect ARMv7A to have NEON, but I'm not sure people expect ARMv7M to have multiple cores.

However, the MP extension has little importance in the back-end, so I won't make much fuzz about it. Whatever you guys think it's best for the default is ok with me.

Maybe see what GCC does? In those unimportant cases, being consistent is always a better strategy. :)

lib/Support/TargetParser.cpp

98

From that doc I infer that sec is v6K/v7A but NOT v8.

159

Well, ok, let me explain what "supported" means. It wasn't a good idea to begin with, tbh.

Supported == ARM describes it as an architecture, so the flag AK_ARMXXX makes sense in the back-end.

The ones below "unsupported", AFAICT, make no difference over the "base" architecture, or are extensions that ARM knows nothing about, like ARMv7L.

But the separation is not clear cut, and when we table-gen it, it will disappear, so I wouldn't worry about it.

[labrinea]

• Added the base features per architecture in ArchNames table.
• Added API to retrieve that info.
• Removed "arm1176j-s" from CPUNames table (invalid processor name).
• Added Cortex-r5f and m4f
• Added bool flags for representing 32/64-bit valid cmd options. However I am not sure they are correct and I recommend to remove these from this patch. They are not used anywhere.

[rengolin]

include/llvm/Support/TargetParser.h

18

Can you also change this comment to be something like:

// FIXME: These includes are necessary for the target feature selection. Once those methods
// move to TargetTuple, they should be removed.

32–33

This is not directly related, but can you move these three methods further down, on their own?

The comment to move them to TargetTuple applies to all three of them, but not to the ones below.

lib/Support/TargetParser.cpp

84

It's possible that these lines are passing the 80-column limits. Maybe align the build attributes to the others on a new line would fix that.

86

You're not using those to parse depending on the arch.

Maybe we should leave them for a separate patch, as this will have to change both ARM back-end and Clang users.

118–119

ARM::AEK_IWMMXT

119

ARM::AEK_XSCALE

149

ARM::AEK_IWMMXT

150

ARM::AEK_XSCALE

154

Don't remove it.

I also saw that it was "invalid", but it was there because GCC accepts it, for whatever reason.

If anything, deprecating this name will have to come on a different patch, after consensus.

154

ARM::AEK_MP? ARM::AEK_SEC?

157

Don't change the arch here. If this is wrong, should be discussed and fixed in a separate patch.

159

Please, don't change *any* ARCH in this patch, nor remove *any* CPU name.

162–164

whitespace change doesn't belong

185

You can't have two default CPUs for the same AK_ARCH

261

this is for a different patch

[richard.barton.arm]

Agree with Renato's comments, apart from one.

lib/Support/TargetParser.cpp

98

Well - the ARMv7-A security extension becomes mandatory in ARMv8-A AArch32. I guess the reason that they call out ARMv6Z and ARMv7-A separately here is that what constitutes "Security Extension" is different between those two arches, whereas in ARMv8-A it is the same as for ARMv7-A just mandatory.

So if that is agreed, then I would expect AArch32 clang to accept this one.

[labrinea]

lib/Support/TargetParser.cpp

118–119

Is this an extension or a base feature? If it is an extension, then it should be removed from base features.

119

Is this an extension or a base feature? If it is an extension, then it should be removed from base features.

149

Is this an extension or a base feature? If it is an extension, then it should be removed from base features.

150

Is this an extension or a base feature? If it is an extension, then it should be removed from base features.

185

oops

261

This is required by D11299 which was split to D11590. Could we avoid the bureaucracy please?

[rengolin]

lib/Support/TargetParser.cpp

149

We don't have *any* logic whatsoever for any of iwmmxt, xscale or maveric features. These are there just for compatibility with GCC, and to recognize the odd triples "xscale-apple-darwin" as ARM.

So, I'm not too fussy about letting those ones be unused.

What you could do is to add a comment on ArchExtNames just before them:

// Unsupported and unused arch extensions

261

Ok, makes sense.

[labrinea]

lib/Support/TargetParser.cpp

84

Most of the tables of this file were already exceeding the 80c limit, but I think respecting this limit makes the tables hardly readable. Also, takes too much time to do this change. Is it worth? Do we really need to?

[rengolin]

lib/Support/TargetParser.cpp

84

Unfortunately, yes.

If they were already, that's my fault for not caring about it then, but that doesn't excuse me for not caring now. :)

[labrinea]

lib/Support/TargetParser.cpp

157

It is not changed. "arm1176j-s" was removed and everything went up one line ;)

159

everything went up one line

[rengolin]

lib/Support/TargetParser.cpp

157

that's what I mean, don't remove/change anything. The repercussions are not always obvious, not even on a clean check-all.

[labrinea]

lib/Support/TargetParser.cpp

154

No, as far as I know.

[labrinea]

Updated according to previous comments.

[rengolin]

lib/Support/TargetParser.cpp

97

I know it's a pain, but can you keep the flags in a separate line on their own if they're more than one? It's hard to follow when the flags are separate.

Then build attributes always aligned to the others.

98

Good point.

101

Wait, if AEK_OS is unused or unsupported, why is it default for so many architectures?

If we argue that IWXMMT, XSCALE and MAVERIC don't need to be applied, I'd argue that OS doesn't either.

162

Shouldn't this get the arch defaults and OR the values before return?

166

Same thing about alignment here

295

You're not using this anywhere, I thought you would use above on getDefaultExtensions at least.

Also, better name them accordingly. We're not yet separating extensions from features, and both are coming from the same place, but associated with a different lookup table, so the name is more than just misleading.

getArchBaseExtensions()
getCPUDefaultExtensions()

would be better candidates, at least for now.

[labrinea]

lib/Support/TargetParser.cpp

101

I will change that in the header file. AEK_OS was considered unsupported. I will change it's value so that it is not at the end of the 32-bit range.

162

I don't understand this. DefaultExtensions is a bitmap that contains all the required information. What values should it OR?

295

This will be used in ARMTargetInfo (see D11299) to get the base arch features. I am OK with renaming them accordingly.

[labrinea]

lib/Support/TargetParser.cpp

162

OK I see what you mean. Yes I agree, I will change this.

[labrinea]

• Changed alignment in tables.
• Removed AEK_OS from unsupported range.
• getCPUDefaultExtensions() returns the OR of arch extensions and cpu extensions.

[rengolin]

include/llvm/Support/TargetParser.h

32

Er, AEK_OS *is* unsupported.

In ARMAsmParser.cpp, structure "Extensions" states it clearly:

// FIXME: Unsupported extensions.
{ ARM::AEK_OS, Feature_None, {} },
{ ARM::AEK_IWMMXT, Feature_None, {} },
{ ARM::AEK_IWMMXT2, Feature_None, {} },
{ ARM::AEK_MAVERICK, Feature_None, {} },
{ ARM::AEK_XSCALE, Feature_None, {} },

What I meant was to remove them from the Arch/CPU tables.

lib/Support/TargetParser.cpp

75

The usage of AEK_NONE here is weird.

If we want NONE to mean "I know there are none", then it should have a specific value (like 0x1) and this should be checked against the other values, like:

assert(Ext & AEK_NONE ? !(Ext & ~AEK_NONE) : true);

This is the semantics I expected it to be when you assigned AEK_NONE = 0x1.

But if we want NONE to mean "I don't know yet", so that we can OR it CPU/Arch values, like you're doing in getCPUDefaultExtensions(), than its value should be 0x0 and we don't need INVALID.

100

Move this back down inside unsupported.

283

So far, we have dealt with front vs back end by hiding the target-features in "setFeatures" functions, that I'd like to go somewhere else later.

The problem is that "idiv" maps to either ARM or Thumb div, which tells nothing about SDIV vs UDIV. I don't particularly like the new options "hwdiv" or "hwdivarm", and they are indeed creating the problem of extending the target-options range to something we might not want to support in the future.

I think we should drop that change for now, only keep what's currently supported by the assembler / front-end, and have this discussion at some other time.

[labrinea]

• removed "hwdiv" and "hwdiv-arm" from extensions table
• removed isBackendOption flag from extensions table
• moved AEK_OS to unsupported and removed it from all table entries
• removed all unsupported extensions from table entries

[labrinea]

Ping

[rengolin]

Hi Alexandros,

I'm afraid this part of the code has changed considerably and you'll have to re-base and probably will have a lot of work to get it back into shape.

cheers,
--renato

[labrinea]

Rebased

[rengolin]

Hi Alexnadros,

Final round of comments, I think the patch is getting into shape to go.

Thanks,
--renato

include/llvm/Support/ARMTargetParser.def

217

HWDIVARM on Cortex-R?

Why AEK_MP here? (and not for the other Rs?)

[labrinea]

include/llvm/Support/ARMTargetParser.def

217

In D11590#215880, @richard.barton.arm wrote:

In D11590#215878, @labrinea wrote:

In D11590#215067, @richard.barton.arm wrote:

Regarding the table, apart from the above Divide concern, I notice also

• the lack of MP extension for Cortex-R5

Are we sure Cortex-R5 has MP extensions?

r0 versions of Cortex-R5 did not have MP extensions. r1 versions do have the MP extensions. My understanding is that clang likes to target the latest revision for cores. If that understanding is correct, then it should have MP extensions.

It's the same for ARM divide. If you take a look at @richard.barton.arm 's first comment, these apply for cortex-r7 too.

[rengolin]

Right, ok. LGTM. Thanks!

[labrinea]

committed as r246930

include/llvm/Support/ARMTargetParser.def

 ARM_FPU("neon-vfpv4", FK_NEON_VFPV4, FV_VFPV4, NS_Neon, FR_None)
 ARM_FPU("neon-fp-armv8", FK_NEON_FP_ARMV8, FV_VFPV5, NS_Neon, FR_None)
 ARM_FPU("crypto-neon-fp-armv8", FK_CRYPTO_NEON_FP_ARMV8, FV_VFPV5, NS_Crypto,
         FR_None)
 ARM_FPU("softvfp", FK_SOFTVFP, FV_NONE, NS_None, FR_None)
 #undef ARM_FPU
 
 #ifndef ARM_ARCH
-#define ARM_ARCH(NAME, ID, CPU_ATTR, SUB_ARCH, ARCH_ATTR)
+#define ARM_ARCH(NAME, ID, CPU_ATTR, SUB_ARCH, ARCH_ATTR, ARCH_BASE_EXT)
 #endif
 ARM_ARCH("invalid", AK_INVALID, nullptr, nullptr,
-         ARMBuildAttrs::CPUArch::Pre_v4)
-ARM_ARCH("armv2", AK_ARMV2, "2", "v2", ARMBuildAttrs::CPUArch::Pre_v4)
-ARM_ARCH("armv2a", AK_ARMV2A, "2A", "v2a", ARMBuildAttrs::CPUArch::Pre_v4)
-ARM_ARCH("armv3", AK_ARMV3, "3", "v3", ARMBuildAttrs::CPUArch::Pre_v4)
-ARM_ARCH("armv3m", AK_ARMV3M, "3M", "v3m", ARMBuildAttrs::CPUArch::Pre_v4)
-ARM_ARCH("armv4", AK_ARMV4, "4", "v4", ARMBuildAttrs::CPUArch::v4)
-ARM_ARCH("armv4t", AK_ARMV4T, "4T", "v4t", ARMBuildAttrs::CPUArch::v4T)
-ARM_ARCH("armv5t", AK_ARMV5T, "5T", "v5", ARMBuildAttrs::CPUArch::v5T)
-ARM_ARCH("armv5te", AK_ARMV5TE, "5TE", "v5e", ARMBuildAttrs::CPUArch::v5TE)
-ARM_ARCH("armv5tej", AK_ARMV5TEJ, "5TEJ", "v5e", ARMBuildAttrs::CPUArch::v5TEJ)
-ARM_ARCH("armv6", AK_ARMV6, "6", "v6", ARMBuildAttrs::CPUArch::v6)
-ARM_ARCH("armv6k", AK_ARMV6K, "6K", "v6k", ARMBuildAttrs::CPUArch::v6K)
-ARM_ARCH("armv6t2", AK_ARMV6T2, "6T2", "v6t2", ARMBuildAttrs::CPUArch::v6T2)
-ARM_ARCH("armv6z", AK_ARMV6Z, "6Z", "v6z", ARMBuildAttrs::CPUArch::v6KZ)
-ARM_ARCH("armv6zk", AK_ARMV6ZK, "6ZK", "v6zk", ARMBuildAttrs::CPUArch::v6KZ)
-ARM_ARCH("armv6-m", AK_ARMV6M, "6-M", "v6m", ARMBuildAttrs::CPUArch::v6_M)
-ARM_ARCH("armv6s-m", AK_ARMV6SM, "6S-M", "v6sm", ARMBuildAttrs::CPUArch::v6S_M)
-ARM_ARCH("armv7-a", AK_ARMV7A, "7-A", "v7", ARMBuildAttrs::CPUArch::v7)
-ARM_ARCH("armv7-r", AK_ARMV7R, "7-R", "v7r", ARMBuildAttrs::CPUArch::v7)
-ARM_ARCH("armv7-m", AK_ARMV7M, "7-M", "v7m", ARMBuildAttrs::CPUArch::v7)
-ARM_ARCH("armv7e-m", AK_ARMV7EM, "7E-M", "v7em", ARMBuildAttrs::CPUArch::v7E_M)
-ARM_ARCH("armv8-a", AK_ARMV8A, "8-A", "v8", ARMBuildAttrs::CPUArch::v8)
-ARM_ARCH("armv8.1-a", AK_ARMV8_1A, "8.1-A", "v8.1a", ARMBuildAttrs::CPUArch::v8)
+          ARMBuildAttrs::CPUArch::Pre_v4, AEK_NONE)
+ARM_ARCH("armv2", AK_ARMV2, "2", "v2", ARMBuildAttrs::CPUArch::Pre_v4,
+          AEK_NONE)
+ARM_ARCH("armv2a", AK_ARMV2A, "2A", "v2a", ARMBuildAttrs::CPUArch::Pre_v4,
+          AEK_NONE)
+ARM_ARCH("armv3", AK_ARMV3, "3", "v3", ARMBuildAttrs::CPUArch::Pre_v4,
+          AEK_NONE)
+ARM_ARCH("armv3m", AK_ARMV3M, "3M", "v3m", ARMBuildAttrs::CPUArch::Pre_v4,
+          AEK_NONE)
+ARM_ARCH("armv4", AK_ARMV4, "4", "v4", ARMBuildAttrs::CPUArch::v4,
+          AEK_NONE)
+ARM_ARCH("armv4t", AK_ARMV4T, "4T", "v4t", ARMBuildAttrs::CPUArch::v4T,
+          AEK_NONE)
+ARM_ARCH("armv5t", AK_ARMV5T, "5T", "v5", ARMBuildAttrs::CPUArch::v5T,
+          AEK_NONE)
+ARM_ARCH("armv5te", AK_ARMV5TE, "5TE", "v5e", ARMBuildAttrs::CPUArch::v5TE,
+          AEK_NONE)
+ARM_ARCH("armv5tej", AK_ARMV5TEJ, "5TEJ", "v5e", ARMBuildAttrs::CPUArch::v5TEJ,
+          AEK_NONE)
+ARM_ARCH("armv6", AK_ARMV6, "6", "v6", ARMBuildAttrs::CPUArch::v6,
+          AEK_NONE)
+ARM_ARCH("armv6k", AK_ARMV6K, "6K", "v6k", ARMBuildAttrs::CPUArch::v6K,
+          AEK_NONE)
+ARM_ARCH("armv6t2", AK_ARMV6T2, "6T2", "v6t2", ARMBuildAttrs::CPUArch::v6T2,
+          AEK_NONE)
+ARM_ARCH("armv6z", AK_ARMV6Z, "6Z", "v6z", ARMBuildAttrs::CPUArch::v6KZ,
+          AEK_SEC)
+ARM_ARCH("armv6zk", AK_ARMV6ZK, "6ZK", "v6zk", ARMBuildAttrs::CPUArch::v6KZ,
+          AEK_SEC)
+ARM_ARCH("armv6-m", AK_ARMV6M, "6-M", "v6m", ARMBuildAttrs::CPUArch::v6_M,
+          AEK_NONE)
+ARM_ARCH("armv6s-m", AK_ARMV6SM, "6S-M", "v6sm", ARMBuildAttrs::CPUArch::v6S_M,
+          AEK_NONE)
+ARM_ARCH("armv7-a", AK_ARMV7A, "7-A", "v7", ARMBuildAttrs::CPUArch::v7,
+          AEK_NONE)
+ARM_ARCH("armv7-r", AK_ARMV7R, "7-R", "v7r", ARMBuildAttrs::CPUArch::v7,
+          AEK_HWDIV)
+ARM_ARCH("armv7-m", AK_ARMV7M, "7-M", "v7m", ARMBuildAttrs::CPUArch::v7,
+          AEK_HWDIV)
+ARM_ARCH("armv7e-m", AK_ARMV7EM, "7E-M", "v7em", ARMBuildAttrs::CPUArch::v7E_M,
+          AEK_HWDIV)
+ARM_ARCH("armv8-a", AK_ARMV8A, "8-A", "v8", ARMBuildAttrs::CPUArch::v8,
+         (AEK_SEC | AEK_MP | AEK_VIRT | AEK_HWDIVARM | AEK_HWDIV))
+ARM_ARCH("armv8.1-a", AK_ARMV8_1A, "8.1-A", "v8.1a", ARMBuildAttrs::CPUArch::v8,
+         (AEK_SEC | AEK_MP | AEK_VIRT | AEK_HWDIVARM | AEK_HWDIV))
 // Non-standard Arch names.
-ARM_ARCH("iwmmxt", AK_IWMMXT, "iwmmxt", "", ARMBuildAttrs::CPUArch::v5TE)
-ARM_ARCH("iwmmxt2", AK_IWMMXT2, "iwmmxt2", "", ARMBuildAttrs::CPUArch::v5TE)
-ARM_ARCH("xscale", AK_XSCALE, "xscale", "", ARMBuildAttrs::CPUArch::v5TE)
-ARM_ARCH("armv5", AK_ARMV5, "5T", "v5", ARMBuildAttrs::CPUArch::v5T)
-ARM_ARCH("armv5e", AK_ARMV5E, "5TE", "v5e", ARMBuildAttrs::CPUArch::v5TE)
-ARM_ARCH("armv6j", AK_ARMV6J, "6J", "v6", ARMBuildAttrs::CPUArch::v6)
-ARM_ARCH("armv6hl", AK_ARMV6HL, "6-M", "v6hl", ARMBuildAttrs::CPUArch::v6_M)
-ARM_ARCH("armv7", AK_ARMV7, "7", "v7", ARMBuildAttrs::CPUArch::v7)
-ARM_ARCH("armv7l", AK_ARMV7L, "7-L", "v7l", ARMBuildAttrs::CPUArch::v7)
-ARM_ARCH("armv7hl", AK_ARMV7HL, "7-L", "v7hl", ARMBuildAttrs::CPUArch::v7)
-ARM_ARCH("armv7s", AK_ARMV7S, "7-S", "v7s", ARMBuildAttrs::CPUArch::v7)
-ARM_ARCH("armv7k", AK_ARMV7K, "7-K", "v7k", ARMBuildAttrs::CPUArch::v7)
+ARM_ARCH("iwmmxt", AK_IWMMXT, "iwmmxt", "", ARMBuildAttrs::CPUArch::v5TE,
+          AEK_NONE)
+ARM_ARCH("iwmmxt2", AK_IWMMXT2, "iwmmxt2", "", ARMBuildAttrs::CPUArch::v5TE,
+          AEK_NONE)
+ARM_ARCH("xscale", AK_XSCALE, "xscale", "", ARMBuildAttrs::CPUArch::v5TE,
+          AEK_NONE)
+ARM_ARCH("armv5", AK_ARMV5, "5T", "v5", ARMBuildAttrs::CPUArch::v5T,
+          AEK_NONE)
+ARM_ARCH("armv5e", AK_ARMV5E, "5TE", "v5e", ARMBuildAttrs::CPUArch::v5TE,
+          AEK_NONE)
+ARM_ARCH("armv6j", AK_ARMV6J, "6J", "v6", ARMBuildAttrs::CPUArch::v6,
+          AEK_NONE)
+ARM_ARCH("armv6hl", AK_ARMV6HL, "6-M", "v6hl", ARMBuildAttrs::CPUArch::v6_M,
+          AEK_NONE)
+ARM_ARCH("armv7", AK_ARMV7, "7", "v7", ARMBuildAttrs::CPUArch::v7,
+          AEK_NONE)
+ARM_ARCH("armv7l", AK_ARMV7L, "7-L", "v7l", ARMBuildAttrs::CPUArch::v7,
+          AEK_NONE)
+ARM_ARCH("armv7hl", AK_ARMV7HL, "7-L", "v7hl", ARMBuildAttrs::CPUArch::v7,
+          AEK_NONE)
+ARM_ARCH("armv7s", AK_ARMV7S, "7-S", "v7s", ARMBuildAttrs::CPUArch::v7,
+          AEK_NONE)
+ARM_ARCH("armv7k", AK_ARMV7K, "7-K", "v7k", ARMBuildAttrs::CPUArch::v7,
+          AEK_NONE)
 #undef ARM_ARCH
 
 #ifndef ARM_ARCH_EXT_NAME
 #define ARM_ARCH_EXT_NAME(NAME, ID)
 #endif
 ARM_ARCH_EXT_NAME("invalid", AEK_INVALID)
 ARM_ARCH_EXT_NAME("none", AEK_NONE)
 ARM_ARCH_EXT_NAME("crc", AEK_CRC)

 ARM_HW_DIV_NAME("invalid", AEK_INVALID)
 ARM_HW_DIV_NAME("none", AEK_NONE)
 ARM_HW_DIV_NAME("thumb", AEK_HWDIV)
 ARM_HW_DIV_NAME("arm", AEK_HWDIVARM)
 ARM_HW_DIV_NAME("arm,thumb", (AEK_HWDIVARM | AEK_HWDIV))
 #undef ARM_HW_DIV_NAME
 
 #ifndef ARM_CPU_NAME
-#define ARM_CPU_NAME(NAME, ID, DEFAULT_FPU, IS_DEFAULT)
+#define ARM_CPU_NAME(NAME, ID, DEFAULT_FPU, IS_DEFAULT, DEFAULT_EXT)
 #endif
-ARM_CPU_NAME("arm2", AK_ARMV2, FK_NONE, true)
-ARM_CPU_NAME("arm3", AK_ARMV2A, FK_NONE, true)
-ARM_CPU_NAME("arm6", AK_ARMV3, FK_NONE, true)
-ARM_CPU_NAME("arm7m", AK_ARMV3M, FK_NONE, true)
-ARM_CPU_NAME("arm8", AK_ARMV4, FK_NONE, false)
-ARM_CPU_NAME("arm810", AK_ARMV4, FK_NONE, false)
-ARM_CPU_NAME("strongarm", AK_ARMV4, FK_NONE, true)
-ARM_CPU_NAME("strongarm110", AK_ARMV4, FK_NONE, false)
-ARM_CPU_NAME("strongarm1100", AK_ARMV4, FK_NONE, false)
-ARM_CPU_NAME("strongarm1110", AK_ARMV4, FK_NONE, false)
-ARM_CPU_NAME("arm7tdmi", AK_ARMV4T, FK_NONE, true)
-ARM_CPU_NAME("arm7tdmi-s", AK_ARMV4T, FK_NONE, false)
-ARM_CPU_NAME("arm710t", AK_ARMV4T, FK_NONE, false)
-ARM_CPU_NAME("arm720t", AK_ARMV4T, FK_NONE, false)
-ARM_CPU_NAME("arm9", AK_ARMV4T, FK_NONE, false)
-ARM_CPU_NAME("arm9tdmi", AK_ARMV4T, FK_NONE, false)
-ARM_CPU_NAME("arm920", AK_ARMV4T, FK_NONE, false)
-ARM_CPU_NAME("arm920t", AK_ARMV4T, FK_NONE, false)
-ARM_CPU_NAME("arm922t", AK_ARMV4T, FK_NONE, false)
-ARM_CPU_NAME("arm9312", AK_ARMV4T, FK_NONE, false)
-ARM_CPU_NAME("arm940t", AK_ARMV4T, FK_NONE, false)
-ARM_CPU_NAME("ep9312", AK_ARMV4T, FK_NONE, false)
-ARM_CPU_NAME("arm10tdmi", AK_ARMV5T, FK_NONE, true)
-ARM_CPU_NAME("arm1020t", AK_ARMV5T, FK_NONE, false)
-ARM_CPU_NAME("arm9e", AK_ARMV5TE, FK_NONE, false)
-ARM_CPU_NAME("arm946e-s", AK_ARMV5TE, FK_NONE, false)
-ARM_CPU_NAME("arm966e-s", AK_ARMV5TE, FK_NONE, false)
-ARM_CPU_NAME("arm968e-s", AK_ARMV5TE, FK_NONE, false)
-ARM_CPU_NAME("arm10e", AK_ARMV5TE, FK_NONE, false)
-ARM_CPU_NAME("arm1020e", AK_ARMV5TE, FK_NONE, false)
-ARM_CPU_NAME("arm1022e", AK_ARMV5TE, FK_NONE, true)
-ARM_CPU_NAME("iwmmxt", AK_ARMV5TE, FK_NONE, false)
-ARM_CPU_NAME("xscale", AK_ARMV5TE, FK_NONE, false)
-ARM_CPU_NAME("arm926ej-s", AK_ARMV5TEJ, FK_NONE, true)
-ARM_CPU_NAME("arm1136jf-s", AK_ARMV6, FK_VFPV2, true)
-ARM_CPU_NAME("arm1176j-s", AK_ARMV6K, FK_NONE, false)
-ARM_CPU_NAME("arm1176jz-s", AK_ARMV6K, FK_NONE, false)
-ARM_CPU_NAME("mpcore", AK_ARMV6K, FK_VFPV2, false)
-ARM_CPU_NAME("mpcorenovfp", AK_ARMV6K, FK_NONE, false)
-ARM_CPU_NAME("arm1176jzf-s", AK_ARMV6K, FK_VFPV2, true)
-ARM_CPU_NAME("arm1176jzf-s", AK_ARMV6Z, FK_VFPV2, true)
-ARM_CPU_NAME("arm1176jzf-s", AK_ARMV6ZK, FK_VFPV2, true)
-ARM_CPU_NAME("arm1156t2-s", AK_ARMV6T2, FK_NONE, true)
-ARM_CPU_NAME("arm1156t2f-s", AK_ARMV6T2, FK_VFPV2, false)
-ARM_CPU_NAME("cortex-m0", AK_ARMV6M, FK_NONE, true)
-ARM_CPU_NAME("cortex-m0plus", AK_ARMV6M, FK_NONE, false)
-ARM_CPU_NAME("cortex-m1", AK_ARMV6M, FK_NONE, false)
-ARM_CPU_NAME("sc000", AK_ARMV6M, FK_NONE, false)
-ARM_CPU_NAME("cortex-a5", AK_ARMV7A, FK_NEON_VFPV4, false)
-ARM_CPU_NAME("cortex-a7", AK_ARMV7A, FK_NEON_VFPV4, false)
-ARM_CPU_NAME("cortex-a8", AK_ARMV7A, FK_NEON, true)
-ARM_CPU_NAME("cortex-a9", AK_ARMV7A, FK_NEON_FP16, false)
-ARM_CPU_NAME("cortex-a12", AK_ARMV7A, FK_NEON_VFPV4, false)
-ARM_CPU_NAME("cortex-a15", AK_ARMV7A, FK_NEON_VFPV4, false)
-ARM_CPU_NAME("cortex-a17", AK_ARMV7A, FK_NEON_VFPV4, false)
-ARM_CPU_NAME("krait", AK_ARMV7A, FK_NEON_VFPV4, false)
-ARM_CPU_NAME("cortex-r4", AK_ARMV7R, FK_NONE, true)
-ARM_CPU_NAME("cortex-r4f", AK_ARMV7R, FK_VFPV3_D16, false)
-ARM_CPU_NAME("cortex-r5", AK_ARMV7R, FK_VFPV3_D16, false)
-ARM_CPU_NAME("cortex-r7", AK_ARMV7R, FK_VFPV3_D16_FP16, false)
-ARM_CPU_NAME("sc300", AK_ARMV7M, FK_NONE, false)
-ARM_CPU_NAME("cortex-m3", AK_ARMV7M, FK_NONE, true)
-ARM_CPU_NAME("cortex-m4", AK_ARMV7EM, FK_FPV4_SP_D16, true)
-ARM_CPU_NAME("cortex-m7", AK_ARMV7EM, FK_FPV5_D16, false)
-ARM_CPU_NAME("cortex-a53", AK_ARMV8A, FK_CRYPTO_NEON_FP_ARMV8, true)
-ARM_CPU_NAME("cortex-a57", AK_ARMV8A, FK_CRYPTO_NEON_FP_ARMV8, false)
-ARM_CPU_NAME("cortex-a72", AK_ARMV8A, FK_CRYPTO_NEON_FP_ARMV8, false)
-ARM_CPU_NAME("cyclone", AK_ARMV8A, FK_CRYPTO_NEON_FP_ARMV8, false)
-ARM_CPU_NAME("generic", AK_ARMV8_1A, FK_NEON_FP_ARMV8, true)
+ARM_CPU_NAME("arm2", AK_ARMV2, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm3", AK_ARMV2A, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm6", AK_ARMV3, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm7m", AK_ARMV3M, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm8", AK_ARMV4, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm810", AK_ARMV4, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("strongarm", AK_ARMV4, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("strongarm110", AK_ARMV4, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("strongarm1100", AK_ARMV4, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("strongarm1110", AK_ARMV4, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm7tdmi", AK_ARMV4T, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm7tdmi-s", AK_ARMV4T, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm710t", AK_ARMV4T, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm720t", AK_ARMV4T, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm9", AK_ARMV4T, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm9tdmi", AK_ARMV4T, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm920", AK_ARMV4T, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm920t", AK_ARMV4T, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm922t", AK_ARMV4T, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm9312", AK_ARMV4T, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm940t", AK_ARMV4T, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("ep9312", AK_ARMV4T, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm10tdmi", AK_ARMV5T, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm1020t", AK_ARMV5T, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm9e", AK_ARMV5TE, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm946e-s", AK_ARMV5TE, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm966e-s", AK_ARMV5TE, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm968e-s", AK_ARMV5TE, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm10e", AK_ARMV5TE, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm1020e", AK_ARMV5TE, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm1022e", AK_ARMV5TE, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("iwmmxt", AK_ARMV5TE, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("xscale", AK_ARMV5TE, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm926ej-s", AK_ARMV5TEJ, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm1136jf-s", AK_ARMV6, FK_VFPV2, true, AEK_NONE)
+ARM_CPU_NAME("arm1176j-s", AK_ARMV6K, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm1176jz-s", AK_ARMV6K, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("mpcore", AK_ARMV6K, FK_VFPV2, false, AEK_NONE)
+ARM_CPU_NAME("mpcorenovfp", AK_ARMV6K, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("arm1176jzf-s", AK_ARMV6K, FK_VFPV2, true, AEK_NONE)
+ARM_CPU_NAME("arm1176jzf-s", AK_ARMV6Z, FK_VFPV2, true, AEK_NONE)
+ARM_CPU_NAME("arm1176jzf-s", AK_ARMV6ZK, FK_VFPV2, true, AEK_NONE)
+ARM_CPU_NAME("arm1156t2-s", AK_ARMV6T2, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm1156t2f-s", AK_ARMV6T2, FK_VFPV2, false, AEK_NONE)
+ARM_CPU_NAME("cortex-m0", AK_ARMV6M, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("cortex-m0plus", AK_ARMV6M, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("cortex-m1", AK_ARMV6M, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("sc000", AK_ARMV6M, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("cortex-a5", AK_ARMV7A, FK_NEON_VFPV4, false, (AEK_SEC | AEK_MP))
+ARM_CPU_NAME("cortex-a7", AK_ARMV7A, FK_NEON_VFPV4, false,
+             (AEK_SEC | AEK_MP | AEK_VIRT | AEK_HWDIVARM | AEK_HWDIV))
+ARM_CPU_NAME("cortex-a8", AK_ARMV7A, FK_NEON, true, AEK_SEC)
+ARM_CPU_NAME("cortex-a9", AK_ARMV7A, FK_NEON_FP16, false, (AEK_SEC | AEK_MP))
+ARM_CPU_NAME("cortex-a12", AK_ARMV7A, FK_NEON_VFPV4, false,
+             (AEK_SEC | AEK_MP | AEK_VIRT | AEK_HWDIVARM | AEK_HWDIV))
+ARM_CPU_NAME("cortex-a15", AK_ARMV7A, FK_NEON_VFPV4, false,
+             (AEK_SEC | AEK_MP | AEK_VIRT | AEK_HWDIVARM | AEK_HWDIV))
+ARM_CPU_NAME("cortex-a17", AK_ARMV7A, FK_NEON_VFPV4, false,
+             (AEK_SEC | AEK_MP | AEK_VIRT | AEK_HWDIVARM | AEK_HWDIV))
+ARM_CPU_NAME("krait", AK_ARMV7A, FK_NEON_VFPV4, false,
+             (AEK_HWDIVARM | AEK_HWDIV))
+ARM_CPU_NAME("cortex-r4", AK_ARMV7R, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("cortex-r4f", AK_ARMV7R, FK_VFPV3_D16, false, AEK_NONE)
+ARM_CPU_NAME("cortex-r5", AK_ARMV7R, FK_NONE, false,
+             (AEK_MP | AEK_HWDIVARM))
+ARM_CPU_NAME("cortex-r5f", AK_ARMV7R, FK_VFPV3_D16, false,
+             (AEK_MP | AEK_HWDIVARM))
+ARM_CPU_NAME("cortex-r7", AK_ARMV7R, FK_VFPV3_D16_FP16, false,
+             (AEK_MP | AEK_HWDIVARM))
+ARM_CPU_NAME("sc300", AK_ARMV7M, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("cortex-m3", AK_ARMV7M, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("cortex-m4", AK_ARMV7EM, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("cortex-m4f", AK_ARMV7EM, FK_FPV4_SP_D16, true, AEK_NONE)
+ARM_CPU_NAME("cortex-m7", AK_ARMV7EM, FK_FPV5_D16, false, AEK_NONE)
+ARM_CPU_NAME("cortex-a53", AK_ARMV8A, FK_CRYPTO_NEON_FP_ARMV8, true, AEK_CRC)
+ARM_CPU_NAME("cortex-a57", AK_ARMV8A, FK_CRYPTO_NEON_FP_ARMV8, false, AEK_CRC)
+ARM_CPU_NAME("cortex-a72", AK_ARMV8A, FK_CRYPTO_NEON_FP_ARMV8, false, AEK_CRC)
+ARM_CPU_NAME("cyclone", AK_ARMV8A, FK_CRYPTO_NEON_FP_ARMV8, false, AEK_CRC)
+ARM_CPU_NAME("generic", AK_ARMV8_1A, FK_NEON_FP_ARMV8, true, AEK_NONE)
 // Non-standard Arch names.
-ARM_CPU_NAME("iwmmxt", AK_IWMMXT, FK_NONE, true)
-ARM_CPU_NAME("xscale", AK_XSCALE, FK_NONE, true)
-ARM_CPU_NAME("arm10tdmi", AK_ARMV5, FK_NONE, true)
-ARM_CPU_NAME("arm1022e", AK_ARMV5E, FK_NONE, true)
-ARM_CPU_NAME("arm1136j-s", AK_ARMV6J, FK_NONE, true)
-ARM_CPU_NAME("arm1136jz-s", AK_ARMV6J, FK_NONE, false)
-ARM_CPU_NAME("cortex-m0", AK_ARMV6SM, FK_NONE, true)
-ARM_CPU_NAME("arm1176jzf-s", AK_ARMV6HL, FK_VFPV2, true)
-ARM_CPU_NAME("cortex-a8", AK_ARMV7, FK_NEON, true)
-ARM_CPU_NAME("cortex-a8", AK_ARMV7L, FK_NEON, true)
-ARM_CPU_NAME("cortex-a8", AK_ARMV7HL, FK_NEON, true)
-ARM_CPU_NAME("cortex-m4", AK_ARMV7EM, FK_NONE, true)
-ARM_CPU_NAME("swift", AK_ARMV7S, FK_NEON_VFPV4, true)
+ARM_CPU_NAME("iwmmxt", AK_IWMMXT, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("xscale", AK_XSCALE, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm10tdmi", AK_ARMV5, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm1022e", AK_ARMV5E, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm1136j-s", AK_ARMV6J, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm1136jz-s", AK_ARMV6J, FK_NONE, false, AEK_NONE)
+ARM_CPU_NAME("cortex-m0", AK_ARMV6SM, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("arm1176jzf-s", AK_ARMV6HL, FK_VFPV2, true, AEK_NONE)
+ARM_CPU_NAME("cortex-a8", AK_ARMV7, FK_NEON, true, AEK_SEC)
+ARM_CPU_NAME("cortex-a8", AK_ARMV7L, FK_NEON, true, AEK_SEC)
+ARM_CPU_NAME("cortex-a8", AK_ARMV7HL, FK_NEON, true, AEK_SEC)
+ARM_CPU_NAME("cortex-m4", AK_ARMV7EM, FK_NONE, true, AEK_NONE)
+ARM_CPU_NAME("swift", AK_ARMV7S, FK_NEON_VFPV4, true,
+             (AEK_HWDIVARM | AEK_HWDIV))
 // Invalid CPU
-ARM_CPU_NAME("invalid", AK_INVALID, FK_INVALID, true)
+ARM_CPU_NAME("invalid", AK_INVALID, FK_INVALID, true, AEK_INVALID)
 #undef ARM_CPU_NAME

include/llvm/Support/TargetParser.h

 // This file implements a target parser to recognise hardware features such as
 // FPU/CPU/ARCH names as well as specific support such as HDIV, etc.
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef LLVM_SUPPORT_TARGETPARSER_H
 #define LLVM_SUPPORT_TARGETPARSER_H
 
 // FIXME: vector is used because that's what clang uses for subtarget feature
 // lists, but SmallVector would probably be better
 #include <vector>
 
 namespace llvm {
 class StringRef;
 
 // Target specific information into their own namespaces. These should be
 // generated from TableGen because the information is already there, and there
 // is where new information about targets will be added.
 // FIXME: To TableGen this we need to make some table generated files available
 // even if the back-end is not compiled with LLVM, plus we need to create a new
 // back-end to TableGen to create these clean tables.
 namespace ARM {
 
 // FPU names.
 enum FPUKind {
 #define ARM_FPU(NAME, KIND, VERSION, NEON_SUPPORT, RESTRICTION) KIND,
 #include "ARMTargetParser.def"
   FK_LAST
 };
 
 // FPU Version
 enum FPUVersion {

 enum FPURestriction {
   FR_None = 0, ///< No restriction
   FR_D16,      ///< Only 16 D registers
   FR_SP_D16    ///< Only single-precision instructions, with 16 D registers
 };
 
 // Arch names.
 enum ArchKind {
-#define ARM_ARCH(NAME, ID, CPU_ATTR, SUB_ARCH, ARCH_ATTR) ID,
+#define ARM_ARCH(NAME, ID, CPU_ATTR, SUB_ARCH, ARCH_ATTR, ARCH_BASE_EXT) ID,
 #include "ARMTargetParser.def"
   AK_LAST
 };
 
 // Arch extension modifiers for CPUs.
 enum ArchExtKind : unsigned {
   AEK_INVALID = 0x0,
   AEK_NONE = 0x1,

 
 StringRef getCanonicalArchName(StringRef Arch);
 
 // Information by ID
 StringRef getFPUName(unsigned FPUKind);
 unsigned getFPUVersion(unsigned FPUKind);
 unsigned getFPUNeonSupportLevel(unsigned FPUKind);
 unsigned getFPURestriction(unsigned FPUKind);
-unsigned getDefaultFPU(StringRef CPU);
-// FIXME: This should be moved to TargetTuple once it exists
+
+// FIXME: These should be moved to TargetTuple once it exists
 bool getFPUFeatures(unsigned FPUKind, std::vector<const char *> &Features);
 bool getHWDivFeatures(unsigned HWDivKind, std::vector<const char *> &Features);
+bool getExtensionFeatures(unsigned Extensions,
+                                   std::vector<const char*> &Features);
+
 StringRef getArchName(unsigned ArchKind);
 unsigned getArchAttr(unsigned ArchKind);
 StringRef getCPUAttr(unsigned ArchKind);
 StringRef getSubArch(unsigned ArchKind);
 StringRef getArchExtName(unsigned ArchExtKind);
 StringRef getHWDivName(unsigned HWDivKind);
+
+// Information by Name
+unsigned  getDefaultFPU(StringRef CPU);
+unsigned  getDefaultExtensions(StringRef CPU);
 StringRef getDefaultCPU(StringRef Arch);
 
 // Parser
 unsigned parseHWDiv(StringRef HWDiv);
 unsigned parseFPU(StringRef FPU);
 unsigned parseArch(StringRef Arch);
 unsigned parseArchExt(StringRef ArchExt);
 unsigned parseCPUArch(StringRef CPU);

lib/Support/TargetParser.cpp

struct {
   const char *NameCStr;
   size_t NameLength;
   ARM::ArchKind ID;
   const char *CPUAttrCStr;
   size_t CPUAttrLength;
   const char *SubArchCStr;
   size_t SubArchLength;
   ARMBuildAttrs::CPUArch ArchAttr; // Arch ID in build attributes.
+  unsigned ArchBaseExtensions;
 
   StringRef getName() const { return StringRef(NameCStr, NameLength); }
 
   // CPU class in build attributes.
   StringRef getCPUAttr() const { return StringRef(CPUAttrCStr, CPUAttrLength); }
 
   // Sub-Arch name.
   StringRef getSubArch() const { return StringRef(SubArchCStr, SubArchLength); }
 } ARCHNames[] = {
-#define ARM_ARCH(NAME, ID, CPU_ATTR, SUB_ARCH, ARCH_ATTR)                      \
+#define ARM_ARCH(NAME, ID, CPU_ATTR, SUB_ARCH, ARCH_ATTR, ARCH_BASE_EXT)       \
   {NAME, sizeof(NAME) - 1, ID, CPU_ATTR, sizeof(CPU_ATTR) - 1, SUB_ARCH,       \
-   sizeof(SUB_ARCH) - 1, ARCH_ATTR},
+   sizeof(SUB_ARCH) - 1, ARCH_ATTR, ARCH_BASE_EXT},
 #include "llvm/Support/ARMTargetParser.def"
 };
 
 // List of Arch Extension names.
 // FIXME: TableGen this.
 struct {
   const char *NameCStr;
   size_t NameLength;
   unsigned ID;
 
   StringRef getName() const { return StringRef(NameCStr, NameLength); }
 } ARCHExtNames[] = {
 #define ARM_ARCH_EXT_NAME(NAME, ID) { NAME, sizeof(NAME) - 1, ID },
 #include "llvm/Support/ARMTargetParser.def"
 };
 
 // List of HWDiv names (use getHWDivSynonym) and which architectural
 // features they correspond to (use getHWDivFeatures).
 // FIXME: TableGen this.
 struct {
   const char *NameCStr;
   size_t NameLength;
   unsigned ID;
 
   StringRef getName() const { return StringRef(NameCStr, NameLength); }
 } HWDivNames[] = {
 #define ARM_HW_DIV_NAME(NAME, ID) { NAME, sizeof(NAME) - 1, ID },
 #include "llvm/Support/ARMTargetParser.def"
 };
 
 // List of CPU names and their arches.
 // The same CPU can have multiple arches and can be default on multiple arches.
 // When finding the Arch for a CPU, first-found prevails. Sort them accordingly.
 // When this becomes table-generated, we'd probably need two tables.
 // FIXME: TableGen this.
 struct {
   const char *NameCStr;
   size_t NameLength;
   ARM::ArchKind ArchID;
   bool Default; // is $Name the default CPU for $ArchID ?
+  unsigned DefaultExtensions;
 
   StringRef getName() const { return StringRef(NameCStr, NameLength); }
 } CPUNames[] = {
-#define ARM_CPU_NAME(NAME, ID, DEFAULT_FPU, IS_DEFAULT) \
-  { NAME, sizeof(NAME) - 1, ID, IS_DEFAULT },
+#define ARM_CPU_NAME(NAME, ID, DEFAULT_FPU, IS_DEFAULT, DEFAULT_EXT) \
+  { NAME, sizeof(NAME) - 1, ID, IS_DEFAULT, DEFAULT_EXT },
 #include "llvm/Support/ARMTargetParser.def"
 };
 
 } // namespace
 
 // ======================================================= //
 // Information by ID
 // ======================================================= //
 
 StringRef llvm::ARM::getFPUName(unsigned FPUKind) {
   if (FPUKind >= ARM::FK_LAST)
     return StringRef();
   return FPUNames[FPUKind].getName();
 }
 
 unsigned llvm::ARM::getFPUVersion(unsigned FPUKind) {
   if (FPUKind >= ARM::FK_LAST)
     return 0;
   return FPUNames[FPUKind].FPUVersion;
 }
 
 unsigned llvm::ARM::getFPUNeonSupportLevel(unsigned FPUKind) {
   if (FPUKind >= ARM::FK_LAST)
     return 0;
   return FPUNames[FPUKind].NeonSupport;
 }
 
 unsigned llvm::ARM::getFPURestriction(unsigned FPUKind) {
   if (FPUKind >= ARM::FK_LAST)
     return 0;
   return FPUNames[FPUKind].Restriction;
 }
 
 unsigned llvm::ARM::getDefaultFPU(StringRef CPU) {
   return StringSwitch<unsigned>(CPU)
-#define ARM_CPU_NAME(NAME, ID, DEFAULT_FPU, IS_DEFAULT) \
+#define ARM_CPU_NAME(NAME, ID, DEFAULT_FPU, IS_DEFAULT, DEFAULT_EXT) \
     .Case(NAME, DEFAULT_FPU)
 #include "llvm/Support/ARMTargetParser.def"
     .Default(ARM::FK_INVALID);
 }
 
 bool llvm::ARM::getHWDivFeatures(unsigned HWDivKind,
                                  std::vector<const char *> &Features) {
 
   if (HWDivKind == ARM::AEK_INVALID)
     return false;
 
   if (HWDivKind & ARM::AEK_HWDIVARM)
     Features.push_back("+hwdiv-arm");
   else
     Features.push_back("-hwdiv-arm");
 
   if (HWDivKind & ARM::AEK_HWDIV)
     Features.push_back("+hwdiv");
   else
     Features.push_back("-hwdiv");
 
   return true;
 }
 
+bool llvm::ARM::getExtensionFeatures(unsigned Extensions,
+                                     std::vector<const char *> &Features) {
+
+  if (Extensions == ARM::AEK_INVALID)
+    return false;
+
+  if (Extensions & ARM::AEK_CRC)
+    Features.push_back("+crc");
+  else
+    Features.push_back("-crc");
+
+  return getHWDivFeatures(Extensions, Features);
+}
+
 bool llvm::ARM::getFPUFeatures(unsigned FPUKind,
                                std::vector<const char *> &Features) {
 
   if (FPUKind >= ARM::FK_LAST || FPUKind == ARM::FK_INVALID)
     return false;
 
   // fp-only-sp and d16 subtarget features are independent of each other, so we
   // must enable/disable both.
case ARM::FV_NONE:
     Features.push_back("-vfp4");
     Features.push_back("-fp-armv8");
     break;
   }
 
   // crypto includes neon, so we handle this similarly to FPU version.
   switch (FPUNames[FPUKind].NeonSupport) {
   case ARM::NS_Crypto:
+    Features.push_back("+neon");
     Features.push_back("+crypto");
     break;
   case ARM::NS_Neon:
     Features.push_back("+neon");
     Features.push_back("-crypto");
     break;
   case ARM::NS_None:
     Features.push_back("-neon");
     Features.push_back("-crypto");
     break;
   }
 
   return true;
 }
 
 StringRef llvm::ARM::getArchName(unsigned ArchKind) {
   if (ArchKind >= ARM::AK_LAST)
     return StringRef();
   return ARCHNames[ArchKind].getName();
 }
 
 StringRef llvm::ARM::getCPUAttr(unsigned ArchKind) {
   if (ArchKind >= ARM::AK_LAST)
     return StringRef();
   return ARCHNames[ArchKind].getCPUAttr();
 }
 
 StringRef llvm::ARM::getSubArch(unsigned ArchKind) {
   if (ArchKind >= ARM::AK_LAST)
     return StringRef();
   return ARCHNames[ArchKind].getSubArch();
 }
 
 unsigned llvm::ARM::getArchAttr(unsigned ArchKind) {
   if (ArchKind >= ARM::AK_LAST)
     return ARMBuildAttrs::CPUArch::Pre_v4;
   return ARCHNames[ArchKind].ArchAttr;
 }
 
 StringRef llvm::ARM::getArchExtName(unsigned ArchExtKind) {
   for (const auto AE : ARCHExtNames) {
     if (ArchExtKind == AE.ID)
       return AE.getName();
   }
   return StringRef();
 }
 
 StringRef llvm::ARM::getHWDivName(unsigned HWDivKind) {
   for (const auto D : HWDivNames) {
     if (HWDivKind == D.ID)
       return D.getName();
   }
   return StringRef();
 }
 
+unsigned llvm::ARM::getDefaultExtensions(StringRef CPU) {
+  for (const auto C : CPUNames) {
+    if (CPU == C.getName())
+      return (ARCHNames[C.ArchID].ArchBaseExtensions | C.DefaultExtensions);
+  }
+  return ARM::AEK_INVALID;
+}
+
 StringRef llvm::ARM::getDefaultCPU(StringRef Arch) {
   unsigned AK = parseArch(Arch);
   if (AK == ARM::AK_INVALID)
     return StringRef();
 
   // Look for multiple AKs to find the default for pair AK+Name.
   for (const auto CPU : CPUNames) {
     if (CPU.ArchID == AK && CPU.Default)