Merge r311659, r311660, r314105 and r317222 into the 5.0.1 branch: Add support for Saphira CPU.

[llvmbot]

Bugzilla Link	35060
Resolution	WONTFIX
Resolved on	Nov 21, 2017 12:18
Version	trunk
OS	Windows NT
Blocks	#33840
Reporter	LLVM Bugzilla Contributor
CC	@tstellar

Extended Description

llvm/r311659:
[TargetParser][AArch64] Add support for RDM feature in the target parser.
Differential Revision: https://reviews.llvm.org/D37081

clang/r311660:
[Driver][AArch64] Add tests for RDM feature.
Differential Revision: https://reviews.llvm.org/D37106

llvm/r314105
[AArch64] Add basic support for Qualcomm's Saphira CPU.

---

This isn't a fix, but I'd still like the patches to be considered as a major feature. The changes are minimally invasive as well.

[tstellar]

The enum changes in https://reviews.llvm.org/rL311659 look like they might break the libLLVM.so ABI.

[llvmbot]

The enum changes in https://reviews.llvm.org/rL311659 look like they might
break the libLLVM.so ABI.

I should be able to fix this by reordering the enums and placing the AEK_RDM enum last, right? If you agree and are good with that solution, I can commit the fix.

[tstellar]

The enum changes in https://reviews.llvm.org/rL311659 look like they might
break the libLLVM.so ABI.

I should be able to fix this by reordering the enums and placing the AEK_RDM
enum last, right? If you agree and are good with that solution, I can
commit the fix.

Yes, I think so. Also you might want to check that the changes to AArch64TargetParser.def don't change the ABI either.

In the past we have accepted code enabling new CPUs. These changes are a little more involved than those changes usually are. Let's get input from Tim too.

Also, r314320 seems unrelated. Did you mean to put r314105 in the summary instead?

[tstellar]

Tim,

Are these OK to merge to the release_50 branch:

https://reviews.llvm.org/rL311659
https://reviews.llvm.org/rL311660
https://reviews.llvm.org/rL314105

[llvmbot]

The enum changes in https://reviews.llvm.org/rL311659 look like they might
break the libLLVM.so ABI.

I should be able to fix this by reordering the enums and placing the AEK_RDM
enum last, right? If you agree and are good with that solution, I can
commit the fix.

Yes, I think so. Also you might want to check that the changes to
AArch64TargetParser.def don't change the ABI either.

Will do.

In the past we have accepted code enabling new CPUs. These changes are a
little more involved than those changes usually are. Let's get input from
Tim too.

Also, r314320 seems unrelated. Did you mean to put r314105 in the summary
instead?

Yes. Thanks for catching this.

[llvmbot]

Posted: https://reviews.llvm.org/D39558
[TargetParser][AArch64] Reorder enum to preserve 5.0.0 libLLVM ABI.

AFAICT, this should address all of the ABI related concerns. However, I would appreciate more eyes on this. :)

[llvmbot]

Posted: https://reviews.llvm.org/D39558
[TargetParser][AArch64] Reorder enum to preserve 5.0.0 libLLVM ABI.

Committed in r317222.

[TNorthover]

Sorry I missed this. These look fine to me for cherry-picking.

[llvmbot]

Sorry I missed this. These look fine to me for cherry-picking.

No problem, Tim. Thanks!

[tstellar]

Chad, can you merge these?

[llvmbot]

In looking at just the AArch64TargetParser.def alone I see a number of additional commits that would need to be merge.

E.g.,
r309287 [TargetParser] Use enum classes for various ARM kind enums.
r310480 [AArch64] Assembler support for the ARMv8.2a dot product instructions
r310561 [ARM][AArch64] ARMv8.3-A enablement
r310708 [AArch64] Remove dotprod from base extension list

All of this adds up to what I would consider an overly complex and error prone merge. Therefore, given the likelihood something would break, I'm just going to close this bug as WONTFIX.