[llvm-bugs] [Bug 50454] New: Some Arm CPUs are only known to either clang or llvm (not both)

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=50454

            Bug ID: 50454
           Summary: Some Arm CPUs are only known to either clang or llvm
                    (not both)
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: david.spickett at linaro.org
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

https://github.com/ClangBuiltLinux/linux/issues/921 reported that doing:
$ ./bin/clang --target=arm-linux-gnueabihf -march=armv3m -c /tmp/test.c -o
/tmp/test.o

Produces:
'arm7m' is not a recognized processor for this target (ignoring processor)
'arm7m' is not a recognized processor for this target (ignoring processor)
'arm7m' is not a recognized processor for this target (ignoring processor)
'arm7m' is not a recognized processor for this target (ignoring processor)
'arm7m' is not a recognized processor for this target (ignoring processor)
'arm7m' is not a recognized processor for this target (ignoring processor)
'arm7m' is not a recognized processor for this target (ignoring processor)
'arm7m' is not a recognized processor for this target (ignoring processor)

Where if you use armv1m, 2m, anything but 4 (or 7/8 which are M profile
architectures) you get:
clang-13: error: the clang compiler does not support '-march=armv4m'

The reason for this is that armv3m is actually a valid arm architecture albeit
a rather old one, and not an M profile arch like armv7-M is.

arm7m (note, no "V" in there) is/was a real CPU that we chose as the default
CPU to use for armv3m. Problem is that llvm doesn't know what this CPU is.

If we compare these two files:
llvm/include/llvm/Support/ARMTargetParser.def (clang side CPUs)
llvm/lib/Target/ARM/ARM.td (backend CPUs)

$ grep -P "^ARM_CPU_NAME" llvm/include/llvm/Support/ARMTargetParser.def | cut
-d\( -f2 | cut -d, -f1 | sort | uniq
$ grep "def : Proc" llvm/lib/Target/ARM/ARM.td | cut -d'<' -f2 | cut -d, -f1

We can see that the lists are not the same:
$ diff /tmp/tpcpus /tmp/tdcpus
8d7
< "arm1136jz-s"
10a10
> "arm1176j-s"
13,15d12
< "arm2"
< "arm3"
< "arm6"
18d14
< "arm7m"
28d23
< "arm9312"
77c72
< "invalid"
---
> "generic"

You can ignore the last two. "invalid" is used as an error value for target
parser functions, and the target parser has no need for a "generic" setting.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210524/8ee5acd1/attachment-0001.html>