arch/risc-v: Refactor LLVM CPU type handling in Toolchain.cmake

[no1wudi]

Summary

• Replace direct string comparisons with regex pattern matching for ARCHCPUEXTFLAGS
• Change from using LLVM_CPUFLAGS list to setting LLVM_CPUTYPE directly
• Simplify CPU type detection logic while maintaining same functionality
• Use more consistent string variable naming convention

This change makes the CPU type detection more flexible and maintainable while keeping the same behavior for supported RISC-V configurations.

Impact

build system only

Testing

GitHub CI and apache/nuttx-apps#2487

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR appears to meet the NuttX requirements, although it could be more thorough. While it addresses the core elements, providing more details in the "Impact" and "Testing" sections would significantly improve clarity and confidence in the changes.

Specifically:

• Impact: While it states "build system only," it lacks details. How does the build process change? Even if seemingly minor, articulating the change (e.g., "Removes the need for an explicit list of CPU flags, simplifying the configuration process.") provides valuable context.
• Testing: Referencing a related PR in nuttx-apps is good, but including specific test results (even summarized) directly within the PR is essential. Simply stating "GitHub CI" is insufficient; mentioning successful builds for specific architectures/configurations strengthens the validation. The "Testing logs before change" and "Testing logs after change" sections are empty, which is against the stated requirements. Even if the behavior is identical, showing some output demonstrating this would be beneficial.

By adding these details, the PR would more robustly adhere to the guidelines, making review easier and increasing confidence in the proposed changes.

[xiaoxiang781216]

but why use a specific vendor chip sifive-e20? @no1wudi

[no1wudi]

For the RISC-V platform, the CPU_TYPE here is typically not utilized (pass to compiler); it is merely used to denote a combination of ISAs. For instance, sifive-e20 represents IMC. This is because LLVM's ARCH_TYPE only specifies RISCV32/RISCV64 and does not reflect the specific ISA. In practical application scenarios, such as in the Rust compiler, sifive-e20 is decoded as riscv32imc and then passed to the Rust compiler.

[xiaoxiang781216]

but why not pass the general riscv32imc directly?

[no1wudi]

Because you can still pass it to compiler as -mcpu param in some case, it can works although it may not be the optimal choice, it will not cause any issues. But riscv32imc can not, it's not a valid identifier in LLVM backend:

nuttx/tools/Zig.defs

Lines 42 to 46 in 724797e

	# Convert cortex-xxx/sifive-exx to cortex_xxx/sifive_exx
	ifneq ($(LLVM_CPUTYPE),)
	ZIGFLAGS += -mcpu $(subst -,_,$(LLVM_CPUTYPE))
	endif

For MCUs, symbols like sifive-e20 are merely used to indicate the ISA types supported by the RISC-V platform and do not entail any substantive optimizations for the CPU core itself.

For example, certain compilers using LLVM, such as wamrc, typically employ --cpu=generic-rv32 in conjunction with the --cpu-features parameter +m,+c to enable support for riscv32imc. In practice, however, this is equivalent to specifying --cpu=sifive-e20.