RISC-V Extension Changes coming to LLVM 22

[lenary]

In LLVM 22.x, we intend to simplify how the C and Zc* extensions are handled in the LLVM backend, in the change llvm/llvm-project#155035. This should more closely align with how these instructions are specified in the RISC-V specification.

In clang, we are relying on the rules implemented in llvm/lib/TargetParser/RISCVISAInfo.cpp to expand out the complex rules around C and the Zc* extensions, to simplify the backend.

This has an impact on other frontends which are not already using the logic in RISCVISAInfo. I'm not sure if this includes Julia or not, but I am filing this issue anyway.

To enable e.g. the Zcf instructions, it will no longer be enough to enable +c,+f in the feature string, +zcf will also be needed. The same applies for +zcd.

I'm not sure exactly how Julia deals with target features, but at the very least the docs here might need to be updated:

julia/doc/src/devdocs/build/riscv.md

Line 42 in 6568124

JULIA_CPU_TARGET := generic-rv64,i,m,a,f,d,zicsr,zifencei,c

It might be easiest to fully expand the list of architecture features, which can be done using a recent build of clang:

$ clang --target=riscv32 -march=rv32imafdc_zicsr_zifencei -print-enabled-extensions
Extensions enabled for the given RISC-V target

    Name                 Version   Description
    i                    2.1       'I' (Base Integer Instruction Set)
    m                    2.0       'M' (Integer Multiplication and Division)
    a                    2.1       'A' (Atomic Instructions)
    f                    2.2       'F' (Single-Precision Floating-Point)
    d                    2.2       'D' (Double-Precision Floating-Point)
    c                    2.0       'C' (Compressed Instructions)
    zicsr                2.0       'Zicsr' (CSRs)
    zifencei             2.0       'Zifencei' (fence.i)
    zmmul                1.0       'Zmmul' (Integer Multiplication)
    zaamo                1.0       'Zaamo' (Atomic Memory Operations)
    zalrsc               1.0       'Zalrsc' (Load-Reserved/Store-Conditional)
    zca                  1.0       'Zca' (part of the C extension, excluding compressed floating point loads/stores)
    zcd                  1.0       'Zcd' (Compressed Double-Precision Floating-Point Instructions)
    zcf                  1.0       'Zcf' (Compressed Single-Precision Floating-Point Instructions)

Experimental extensions

ISA String: rv32i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0_zifencei2p0_zmmul1p0_zaamo1p0_zalrsc1p0_zca1p0_zcd1p0_zcf1p0

Where the first column gives the list of extension feature names to enable. (The same can be done with e.g. -mcpu=<cpu name> or -march=<profile name> instead of -march=<arch>, if that better represents the intention of the specific build).

The extension lists will not always match between rv32 and rv64, so care should be taken when doing this change.

[giordano]

I believe that for choosing the target ISA we rely on llc, would that be sufficient or we need to make further adaptations? Also, would the extension rv64gc be interpreted as before or we'd need to add +zcf?

[lenary]

clang will never interpret rv64gc as including zcf (zcf is 32-bit only), but clang does enable zcd when providing rv64gc (this is done by RISCVISAInfo). Clang will interpret rv32gc as including zcf.

llc does not consult RISCVISAInfo, it takes the list of features as provided, so your frontend will need to interpret them correctly.