[clang] [llvm] [ARM] Armv8-R does not require fp64 or neon. (PR #88287)

Peter Smith via cfe-commits cfe-commits at lists.llvm.org
Fri May 3 02:37:42 PDT 2024


smithp35 wrote:

I can chime in with an opinion but unfortunately I think it may be different to everyone elses!

This is a bit of an awkward situation as I think we have to balance several things:
* Consistency between v8-R and AArch32 (ARM) and AArch64 (more consistent the better)
* Consistency between clang and gcc (more consistent the better)
* Historical behaviour of -march=armv8-r (how often is it used vs -mcpu)
* Historical behaviour of -mcpu=cortex-r82 (keeping these stable as this is the most specific target)
* Consistency with other -march and -mcpu with respect to feature enablement heuristics (helps transition between options).

As a general rule/heuristic for Arm feature enablement going forward, you will find exceptions to these rules in LLVM, particularly pre Armv8. we tend towards:
* -march enables the mandatory features, but not the optional features, with specific exceptions such as SVE for Armv9 and floating point and SIMD for AArch64 Armv8
* -mcpu enables the mandatory and optional features, with specific exceptions such as crypto

The Cortex-R series are intended for deeply embedded applications so it is normally possible for a user to directly target the CPU rather than the architecture. As there is only one v8-R CPU I'm fully expecting most users to use `-mcpu=cortex-r82` rather than `-march=armv8-r`.

With these in mind. I propose:
* `-march=armv8-r` enables the mandatory architectural features and including the mandatory minimum FPU given that all implementations of v8-R have that. It doesn't make sense to make it optional for puritys sake.
* Make `-march=armv8-r` use a generic CPU so that we don't need to change cortex-r82. Yes this will make the performance of v8-R worse without `-mtune`, but I think it is preferable to keep -mcpu=cortex-r82 unaltered as that is what most people will  be using.
* Do not change -mcpu=cortex-r82 from its current default.

This is again an opinion based the weights that I put on the trade-off dimensions.


https://github.com/llvm/llvm-project/pull/88287


More information about the cfe-commits mailing list