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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to