This is an archive of the discontinued LLVM Phabricator instance.

[LLVM][ARM] Remove options for armv2, 2A, 3 and 3M
ClosedPublic

Authored by DavidSpickett on Sep 1 2022, 6:54 AM.

Details

Summary

Fixes #57486

These pre v4 architectures are not specifically supported
by codegen. As demonstrated in the linked issue.

GCC has not supported 3M since GCC 9 and presumably
2 and 2A earlier than that. So we are aligned in that sense.

(see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2abd6e34fcf3bd9f9ffafcaa47cdc3ed443f9add)

This removes the options and associated testing.

The Pre_v4 build attribute remains mainly because its absence
would be more confusing. It will not be used other than to
complete the list of build attributes as shown in the ABI.

https://github.com/ARM-software/abi-aa/blob/main/addenda32/addenda32.rst#3352the-target-related-attributes

Diff Detail

Event Timeline

DavidSpickett created this revision.Sep 1 2022, 6:54 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2022, 6:54 AM
DavidSpickett requested review of this revision.Sep 1 2022, 6:54 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptSep 1 2022, 6:54 AM

The remaining reference in the repo is a #define in openmp/runtime/src/kmp_platform.h which seems harmless.

peter.smith accepted this revision.Sep 1 2022, 8:19 AM
peter.smith added a subscriber: peter.smith.

LGTM. GCC no longer supports Arm architecture prior to v4 so it is likely the alternative of adding support for v3 is not worth it. The only Arm machines running v2 are likely to be the Acorn Archimedes family, these have their own object file format so are unlikely to benefit from LLVM support.

Agree that the openmp reference looks harmless.

Will be worth waiting to see if Nick has any objections.

This revision is now accepted and ready to land.Sep 1 2022, 8:19 AM
nickdesaulniers accepted this revision.Sep 1 2022, 9:56 AM

For the Linux kernel, we're only building v5+ continuously.

It looks like the Linux kernel supports v4+ and v3m (for Acorn Risc-PC (Intel StrongARM(R) SA-110)). We've never been able to build that target, and it's not high ROI to do so.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/Makefile#n74

GCC no longer supports Arm architecture prior to v4 so it is likely the alternative of adding support for v3 is not worth it.

Oh, looks like the kernel already has a check for (6 <= GCC < 9.1), so there's no risk of breakage on our side. Thanks for the heads up though!
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2abd6e34fcf3bd9f9ffafcaa47cdc3ed443f9add

Consider amending the commit message to mention the specific version of GCC that support for v3- was removed from.

DavidSpickett edited the summary of this revision. (Show Details)Sep 2 2022, 1:50 AM

This is probably overkill but I posted an RFC just in case https://discourse.llvm.org/t/rfc-removal-of-armv2-2a-3-3m-target-options/65040. Like I said, no rush to land this.

rengolin accepted this revision.Sep 2 2022, 3:56 AM
rengolin added a subscriber: rengolin.

Agree. Even 10 years ago we made the concerted effort not to care about pre-v4, so I'd be a little surprised if people are actually using modern clang to target those platforms.

Projects that rely on it can work in the same way as gcc and pick an older version of the toolchains.

This revision was automatically updated to reflect the committed changes.

1:38 AM <arnd> might be good to take them out here as well

So I looked into this. Here are the Arm architectures that clang has that
gcc doesn't:
"armv5tej" Not in GCC, j = jazelle
"armv7k"
Apple Watch S1
"armv7s" // iPhone 5
"xscale"

(minus some very new ones that are just because I used trunk clang)

These are the gcc architectures that clang doesn't have:
"armv6j"
"armv6s-m"
"armv6z"
"armv6zk"
"armv7"

So a random grab bag of v6 and 7 on both sides. Not worth disturbing that
now.

Arnd picked out jazelle. GCC doesn't list armv5tej but it does accept it
https://godbolt.org/z/cazcbfjGY. For armv6j clang doesn't list it but it
also does accept it https://godbolt.org/z/aEKfnojTY.

llvm's support for jazelle is a single instruction "bxj" which is a branch
exchange, but for jazelle (
https://developer.arm.com/documentation/dui0473/j/arm-and-thumb-instructions/bxj
).
Which makes some sense. If you had that one instruction you could compile
99% of the code with public toolchains, then the rest with some tool from
Arm, I guess. GCC appears to have done the same.

So targets wise I think things are fine as is unless a v6 enthusiast tries
to use clang sometime.

For jazelle the bxj instruction appears to be present on non jazelle
processors, and can be used as a normal bx in ThumbEE. The code to
implement it and the armv5tej target is minimal and compact so I think we
keep it for now.

I think we can safely say that we care less about jazelle than we care about armv1/2/3, so feel free to ignore that, too.

llvm/test/MC/ARM/directive-arch-armv3.s