arm64: Use .arch armv8-4.a with GNU as for extensions to tlbi

[jhb]

Summary

GNU as does not support a tlb-rmi architecture extension to selectively
enable access to this part of ARMv8.4-A. Instead, it has to be enabled
by selecting a suitable -march.

[jhb]

Using .arch here is not entirely future proof, but does work. The Linux kernel doesn't use .arch_extension. It figures out the highest configured -march= value, and for binutils it passes that to GNU as via -Wa,-march=<mumble> but for clang it uses .arch <mumble> via a special wrapper macro. That approach though spans the entire kernel build for GNU as, whereas this approach only affects pmap.c so will hopefully be easier to update if needed in the future.

For some related reading: https://www.sourceware.org/bugzilla/show_bug.cgi?id=26339

[andrew]

Why not use the new SYS_ARG macro? The tlbi instructions are in the sys instruction space.

[andrew]

I created macros in D59147 & D59148 to use the SYS_ARG macro

[alc]

I'm curious as to why this isn't also a problem for the uses of .arch_extension in arm64/vfp.c, arm64/mte.c, and include/atomic.h?

[jhb]

In D59105#1359613, @alc wrote:

I'm curious as to why this isn't also a problem for the uses of .arch_extension in arm64/vfp.c, arm64/mte.c, and include/atomic.h?

Because clang and binutils have different views about .arch_extension. binutils does support .arch_extension, but for fewer extensions (and the two toolchains sometimes uses different names). The bug report quoted above contains some of this (e.g. in comment 2)

I think a problem we've got here is that in LLVM there are all these "backend features" that do not correspond to the notional user-facing features in Clang, but which are nevertheless exposed to users through the assembler and .arch_extension.

Thus, GCC and Clang agree on +memtag being the option to enable MTE. But gas follows GCC and uses +memtag to enable it, whereas in LLVM the "internal feature" ends up being "+mte", which is what the assembler demands instead of +memtag.

Similar for 'tlb-rmi', I think introduced through https://github.com/llvm/llvm-project/commit/9c9067316be2b802a3af689b94aadc2740a47bcc

Reading through the rationale at http://lists.llvm.org/pipermail/llvm-dev/2018-September/126346.html
it looks like LLVM made the conscious step of breaking compatibility with GNU, which is unfortunate.

For the future, it would be great if both the Clang-level and the assembly-level feature strings in LLVM aligned (and we can ensure they're aligned with GCC and gas).

For the current inconsistencies, we have some options of resolving the pain.
LLVM can add +memtag as an alias for +mte to its "backend feature".

The other extension we need to resolve is 'tlb-rmi'. It is a mandatory part of Armv8.4-A. It cannot be enabled at the Clang level, only at the assembler level, as it's one of those "backend features". gas doesn't support the extension string and gates these instructions on -march=armv8.4-a. I think that behaviour is aligned with what LLVM did with https://github.com/llvm/llvm-project/commit/9c9067316be2b802a3af689b94aadc2740a47bcc

Any ideas on how to proceed?

I've ok'd Andy's other approach for now.