[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