[TargetParser][AArch64] Reorder enum to preserve 5.0.0 libLLVM ABI.

[mcrosier]

Summary

This is required for backporting r311659 to the 5.0.1 release, which is a prerequisite for backporting support for Qualcomm's Saphira CPU to the 5.0.1 release.
PR35060

[rengolin]

Why did they change in the first place?

[rengolin]

Ha, I see. That was your commit trying to reorder things. :) LGTM.

[javed.absar]

Would it make sense to add a test, so that any future changes doesn't undo this behaviour?

[mcrosier]

In D39558#914116, @javed.absar wrote:

Would it make sense to add a test, so that any future changes doesn't undo this behaviour?

rL311659 (which reordered the enum in the first place) already has test coverage, however, I don't think that's the kind of testing you're suggesting.

I think what you're suggesting is that we add unit tests to ensure the enums don't get reordered. AFAIK, we don't have a hard/fast rule for this (I could easily be mistaken). IIUC the issue only arises when you want to backport a change so that, for example, the libLLVM.so shipped with the 5.0.0 release is compatible with the 5.0.1 release. I don't know if we ensure major releases are compatible with this respect to one another.

Do you have any thoughts on this, Renato?

[mcrosier]

In D39558#914088, @rengolin wrote:

Why did they change in the first place?

The reordering was arbitrary, but I didn't realize the implications at the time. :/

[rengolin]

In D39558#914157, @mcrosier wrote:

In D39558#914088, @rengolin wrote:

Why did they change in the first place?

The reordering was arbitrary, but I didn't realize the implications at the time. :/

Been there, done that. :)

I don't think we need tests for testing the ordering. The original patch already had tests, we should be fine.

Also, this would be good to be on trunk as well as 5.0. We can't break binary compatibility between dot-releases, but we shouldn't do so on normal releases either, unless there's a reason.

--renato

[mcrosier]

In D39558#914158, @rengolin wrote:

In D39558#914157, @mcrosier wrote:

In D39558#914088, @rengolin wrote:

Why did they change in the first place?

The reordering was arbitrary, but I didn't realize the implications at the time. :/

Been there, done that. :)

I don't think we need tests for testing the ordering. The original patch already had tests, we should be fine.

Also, this would be good to be on trunk as well as 5.0. We can't break binary compatibility between dot-releases, but we shouldn't do so on normal releases either, unless there's a reason.

I agree.

--renato

llvm/trunk/include/llvm/Support/TargetParser.h

enum ArchExtKind : unsigned {
   AEK_CRC =         1 << 1,
   AEK_CRYPTO =      1 << 2,
   AEK_FP =          1 << 3,
   AEK_SIMD =        1 << 4,
   AEK_FP16 =        1 << 5,
   AEK_PROFILE =     1 << 6,
   AEK_RAS =         1 << 7,
   AEK_LSE =         1 << 8,
-  AEK_RDM =         1 << 9,
-  AEK_SVE =         1 << 10,
-  AEK_DOTPROD =     1 << 11,
-  AEK_RCPC =        1 << 12
+  AEK_SVE =         1 << 9,
+  AEK_DOTPROD =     1 << 10,
+  AEK_RCPC =        1 << 11,
+  AEK_RDM =         1 << 12
 };
 
 StringRef getCanonicalArchName(StringRef Arch);
 
 // Information by ID
 StringRef getFPUName(unsigned FPUKind);
 ARM::FPUVersion getFPUVersion(unsigned FPUKind);
 ARM::NeonSupportLevel getFPUNeonSupportLevel(unsigned FPUKind);