CSRs defined in sstc extension

Code Generation RISCV
1

Hello!
In patch D117311 some CSRs defined in sstc extension are added, and it looks these CSRs are defined no matter sstc extension is turned on or off.
My question is why there is no switch to control definition of CSRs, as there is “FeaturesRequired” field to help control definition of CSRs with certain features?
Thanks!

2

There’s a bit of history here - the splitting of CSRs was initially messy - sometimes there wasn’t an extension name to describe the CSR, or there were later changes that would be backwards incompatible if we were gating CSRs on a particular extensions (e.g. zicntr, zihpm). Our current behaviour is documented here User Guide for RISC-V Target — LLVM 17.0.0git documentation

I think gating CSR names for more recent extensions would likely be fine (and perhaps a minor improvement), but it hasn’t been a priority for anyone.

3

Thanks for reply!
May I have another question that for now I’m trying to add a cpu with extensions sstc, smstateen and so on, and supports pass attributes related to these extensions. Is it fine to add features for these extensions and gating CSRs defined by these extension by adding features to “FeaturesRequired” field? Or any other suggestion?

4

Assemblers for other targets don’t usually require you to specify which features are enabled. This is a uniqueness of RISC-V because of instruction encodings being reused between different incompatible extensions.

I’m not sure if CSR encodings are going to get reused like instruction encodings. That might be one reason to check CSR names based on extension.

Is an error going to help users catch issues or are they going to put the extension on the command line just to satisfy the tool?