[RISCV] Do we need to change the default configuration to rva23u64

[wangpc-pp]

When there is no -march/-mcpu specified, the default configuration is rv64imafdc (RVA20) now. This is not a problem.
There are some updates that some distros are going to move to RVA23. For example, Ubuntu:

And also openEuler (the one ISCAS/PLCT is mantaining). Besides, I asked one mantainer of Debian RISC-V about this, it may be possible to move to RVA23 in Debian 14.

So, should we do the same thing in toolchain? If so, when? I know we can achieve the same thing via Clang configurations (problematic, see comments in Generate configuration files for clang/clang++ by wangpc-pp · Pull Request #1548 · riscv-collab/riscv-gnu-toolchain · GitHub), here I just want to gather some insights about this.

[asb]

Thanks for starting the discussion! My immediate question is if there is any advantage you see to being ahead of the distros here? My natural inclination would have been to wait until distros start to shift and then evaluate.

I think we should also separate out any issues with compile-time default march/mcpu settings or configuration files from the consideration about changing the default. If the mechanisms for shipping a compiler that has a different default architectural baseline don’t work well, we should find a way to fix them as changing the default is of course not going to solve the problem wherever you have different communities preferring different defaults.

[wangpc-pp]

@asb

Thanks for starting the discussion! My immediate question is if there is any advantage you see to being ahead of the distros here? My natural inclination would have been to wait until distros start to shift and then evaluate.

Yeah, that is a good question. I don’t see any advantage, just want to know the opinions of toolchain community members. If I must name an advantage, I think it may speed up the porting progress of RVA23.

@asb

I think we should also separate out any issues with compile-time default march/mcpu settings or configuration files from the consideration about changing the default. If the mechanisms for shipping a compiler that has a different default architectural baseline don’t work well, we should find a way to fix them as changing the default is of course not going to solve the problem wherever you have different communities preferring different defaults.

Good point! I have tried to fix the configuration file issue months ago but it was not so easy and I put it aside. I will pick it up again later. And, I don’t know if it is a common practice that the distros will distribute Clang/LLVM compiler with a pre-defined configuration file (at least I don’t see it on X86 distros, maybe it is because it has good native detection mechanisms).