[PATCH] D133109: [LLVM][ARM] Remove options for armv2, 2A, 3 and 3M

David Spickett via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 15 07:29:30 PDT 2022


DavidSpickett added subscribers: nickdesaulniers, psmith.
DavidSpickett added a comment.

> 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.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133109/new/

https://reviews.llvm.org/D133109



More information about the llvm-commits mailing list