[clang][ARM] Remove arm2/3/6/7m CPU names

[DavidSpickett]

Summary

These legacy CPUs are known to clang but not llvm.
Their use was ignored by llvm and it would print a
warning saying it did not recognise them.

However because some of them are default CPUs for their
architecture, you would get those warnings even if you didn't
choose a cpu explicitly.
(now those architectures will default to a "generic" CPU)

Information is thin on the ground for these older chips
so this is the best I could find:
https://en.wikichip.org/wiki/acorn/microarchitectures/arm2
https://en.wikichip.org/wiki/acorn/microarchitectures/arm3
https://en.wikichip.org/wiki/arm_holdings/microarchitectures/arm6
https://en.wikichip.org/wiki/arm_holdings/microarchitectures/arm7

Final part of fixing https://bugs.llvm.org/show_bug.cgi?id=50454.

[DavidSpickett]

@nickdesaulniers With this you won't get warnings for https://github.com/ClangBuiltLinux/linux/issues/921.

[peter.smith]

Does LLVM generate correct code for those architectures? For example armv3 doesn't have BX LR, it must use MOV PC, LR or emit BX LR with an R_ARM_V4BX relocation so the linker can transform it. From memory I think armv2 doesn't even use 32-bit addresses, the flags were stored in the top 8 bits.

[efriedma]

The ARM documentation people usually use doesn't document anything older than v4, and I've never seen anyone use those targets. I'd rather just reject them from clang.

[DavidSpickett]

@nickdesaulniers Can you confirm whether the kernel CI report you got was intentionally setting armv3m? If the build isn't setting an mcpu then removing the CPUs won't actually break it, though what it generates likely wouldn't run correctly.

In the meantime I will have a scan through the code and see if this armv4 minimum is evident in llvm. Then update this change to remove the CPUs from clang.

[nickdesaulniers]

In D103028#2778991, @DavidSpickett wrote:

@nickdesaulniers Can you confirm whether the kernel CI report you got was intentionally setting armv3m? If the build isn't setting an mcpu then removing the CPUs won't actually break it, though what it generates likely wouldn't run correctly.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/Makefile#n74 explicitly sets -march=armv3m, when trying to build CONFIG_CPU_32v3. We don't yet support v4 or v4t FWIW.

[efriedma]

I found some discussion at https://patchwork.kernel.org/project/linux-arm-kernel/patch/[e-mail]/ . Apparently, the kernel is actually intentionally building for "ARMv3M" by default, to support some ancient hardware that doesn't support all the armv4 instructions. LLVM doesn't support this at the moment. We shouldn't accept -march=armv3m unless we're actually going to generate correct code for it.

We don't yet support v4 or v4t FWIW.

Not sure what you mean by this?

[nickdesaulniers]

In D103028#2791630, @efriedma wrote:

I found some discussion at https://patchwork.kernel.org/project/linux-arm-kernel/patch/[e-mail]/ . Apparently, the kernel is actually intentionally building for "ARMv3M" by default,

(when targeting armv3 hardware, not in general)

to support some ancient hardware that doesn't support all the armv4 instructions. LLVM doesn't support this at the moment. We shouldn't accept -march=armv3m unless we're actually going to generate correct code for it.

We don't yet support v4 or v4t FWIW.

Not sure what you mean by this?

Folks building the Linux kernel with Clang do not have working configurations of the Linux kernel that target ARMv4 hardware. I don't know the list of blockers, and it's not a high priority. Clang may support ARMv4, but that doesn't mean a kernel with such configuration with build let alone boot.

[DavidSpickett]

Instead of adding CPUs to llvm, remove them from clang.

If anyone was using them they weren't making any difference,
apart from generating warnings.

I checked the linux tree and found only 2 similair strings.
A Freescale "Armardillo2" aka arm2 board, which is actually using
a cortex A-9, and a comment in a file for the ARM720 which
is actually an ARM7TDMI-S CPU.

Whether we generate correct code for pre v4 is a
question for a different time, so the architectures remain.

[DavidSpickett]

clang/test/Misc/target-invalid-cpu-note.c

4 ↗

(On Diff #349221)

Despite the triple being armv5, clang just prints every CPU it knows about. The arm8 is now the first one.

[efriedma]

LGTM

[DavidSpickett]

Clang format

llvm/lib/Target/ARM/ARM.td

 // ARM processors
 //
 // Dummy CPU, used to target architectures
 def : ProcessorModel<"generic",     CortexA8Model,      []>;
 
 // FIXME: Several processors below are not using their own scheduler
 // model, but one of similar/previous processor. These should be fixed.
 
+def : ProcNoItin<"arm2",                                [ARMv2]>;
+def : ProcNoItin<"arm3",                                [ARMv2a]>;
+def : ProcNoItin<"arm6",                                [ARMv3]>;
+def : ProcNoItin<"arm7m",                               [ARMv3m]>;
+
 def : ProcNoItin<"arm8",                                [ARMv4]>;
 def : ProcNoItin<"arm810",                              [ARMv4]>;
 def : ProcNoItin<"strongarm",                           [ARMv4]>;
 def : ProcNoItin<"strongarm110",                        [ARMv4]>;
 def : ProcNoItin<"strongarm1100",                       [ARMv4]>;
 def : ProcNoItin<"strongarm1110",                       [ARMv4]>;
 
 def : ProcNoItin<"arm7tdmi",                            [ARMv4t]>;

llvm/test/CodeGen/ARM/pr50454.ll

+;; At one point these CPUs were only know to Clang because
+;; they were defined in the Arm target parser but not in ARM.td.
+
+; RUN: llc < %s -mtriple=armv2-unknown-eabi -mcpu=arm2 2>&1 | FileCheck %s
+; RUN: llc < %s -mtriple=armv2a-unknown-eabi -mcpu=arm3 2>&1 | FileCheck %s
+; RUN: llc < %s -mtriple=armv3-unknown-eabi -mcpu=arm6 2>&1 | FileCheck %s
+; RUN: llc < %s -mtriple=armv3m-unknown-eabi -mcpu=arm7m 2>&1 | FileCheck %s
+
+; CHECK-NOT: {{.*}} is not a recognized processor for this target (ignoring processor)