Archdetect riscv update

[hugomeiland]

This update will treat the isa line from a riscv cpu (e.g. rv64imafdcv_zicbom_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zfhmin_zca_zcd_zba_zbb_zbc_zbs_zkt_zve32f_zve32x_zve64d_zve64f_zve64x_zvfh_zvfhmin_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt) and sed it into seperate flags which can be matched as relevant (!) features, the same way we do for x86_64. This should allow cpu's with the same relevant features, but from different vendors to be matched to the same cpu paths.

[julianmorillo]

I think this update makes sense as it certainly gives more flexibility and would allow working with subsets of extensions instead of matching the whole ISA string. I suggest to change the comment in eessi_archdetect.sh to something like:

# RISC-V ISA strings use '_' as extension separators.
# Convert them to space-separated feature tokens so they
# can be matched like x86 CPU flags.

as it explains better why the replacement is done. The tokens here are just features/extensions and do not translate to compilation flags (in contrast with x86). At the end, when building we will need the ISA string (with underscores) anyway to pass it to the -march option.

Which makes me think... if we do:

bot: build repo:dev.eessi.io-riscv-2025.06-001 instance:eessi-bot-riscv for:arch=riscv64/sifive/p550

where/how is the ISA string to pass to -march determined? Doesn't it directly come from init/arch_specs/eessi_arch_riscv.spec ? I think this would require an update at some other script...

[riscv-eessi-io-bot]

New job on instance eessi-bot-riscv for repository dev.eessi.io-riscv-2025.06-001
Building on: sifive-p550
Building for: riscv64/sifive/p550
Job dir: /home/eessibot/shared/jobs/2026.06/pr_243/309668

date	job status	comment
Jun 03 13:06:42 UTC 2026	submitted	job id 309668 awaits release by job manager
Jun 03 13:07:07 UTC 2026	released	job awaits launch by Slurm scheduler
Jun 03 13:08:15 UTC 2026	running	job 309668 is running
Jun 03 13:09:22 UTC 2026	finished	🤷 UNKNOWN (click triangle for detailed information) Job results file _bot_job309668.result does not exist in job directory, or parsing it failed. No artefacts were found/reported.
Jun 03 13:09:22 UTC 2026	test result	🤷 UNKNOWN (click triangle for detailed information) Job test file _bot_job309668.test does not exist in job directory, or parsing it failed.

[hugomeiland]

At the end, when building we will need the ISA string (with underscores) anyway to pass it to the -march option.

Which makes me think... if we do:

bot: build repo:dev.eessi.io-riscv-2025.06-001 instance:eessi-bot-riscv for:arch=riscv64/sifive/p550

where/how is the ISA string to pass to -march determined? Doesn't it directly come from init/arch_specs/eessi_arch_riscv.spec ? I think this would require an update at some other script...

llvm: Supported profile names can be passed using -march instead of a standard ISA naming string. Currently supported profiles:
rvi20u32
rvi20u64
rva20u64
rva20s64
rva22u64
rva22s64
rva23u64
rva23s64
rvb23u64
rvb23s64

GCC: -march=[ISA|Profile|Profile_ISA|processor-string]

Generate code for given RISC-V ISA or profile or a combination of them (e.g. ‘rv64im’ ‘rvi20u64’ ‘rvi20u64_zbb’). The names of ISAs and profiles must be lower case. Examples include ‘rv64i’, ‘rv32g’, ‘rv32e’, ‘rv32imaf’, ‘rva22u64’ and ‘rva23u64’. 

so if we use the profile name as the naming of the cpu, it can directly be used in the compilers...

[casparvl]

where/how is the ISA string to pass to -march determined? Doesn't it directly come from init/arch_specs/eessi_arch_riscv.spec ? I think this would require an update at some other script...

I'm not sure if I understand your question correctly, but: in principle, all our builds use the default value for EasyBuild's optarch setting - meaning they optimize for the current build host. GPU builds do take the GPU target passed to the bot and set that as EASYBUILD_CUDA_COMPUTE_CAPABILITIES argument for EasyBuild. I'm not 100% sure what our generic CPU builds though - they might just be native builds on the oldest target we have access to - or they might actually set some EASYBUILD_OPTARCH somewhere. You should check the build scripts for this.

So yeah, making archspec aware of these architectures is only the first step. For CPU builds, native building was never an issue - but the same might not apply to Risc-V... In that case the build scripts would need to start setting some EASYBUILD_OPTARCH I guess...

[hugomeiland]

Folded the remaining useful bits from #234 into this PR:

• Renamed riscv64/sifive/jh7110 → riscv64/sifive/u74-mc (matches /proc/cpuinfo uarch: sifive,u74-mc and GCC -mtune=sifive-u74)
• Ported VisionFive 2 archdetect fixtures under tests/archdetect/riscv64/sifive/u74-mc/
• Moved p550 fixtures to tests/archdetect/riscv64/sifive/p550/ and updated the CI matrix

Tokenized ISA matching from this PR is kept. Local RISC-V archdetect tests for p550, u74-mc, and both SpacemiT cases pass.

Closing #234 as superseded by this PR.

[hugomeiland]

Build-time RISC-V optarch map

Added the complementary piece to archdetect (runtime selection):

• init/arch_specs/eessi_riscv_optarch.map — software_subdir → EASYBUILD_OPTARCH (-march / -mtune / -mabi, or GENERIC)
• init/eessi_riscv_optarch.sh — lookup + apply helpers
• Wired into bot/build.sh and EESSI-install-software.sh (honours pre-set EASYBUILD_OPTARCH / --generic)
• Copied via install_scripts.sh
• CI: .github/workflows/tests_riscv_optarch.yml

Example: riscv64/sifive/u74-mc → -march=rva20u64 -mtune=sifive-u74 -mabi=lp64d

[hugomeiland]

GCC + Clang/LLVM optarch coverage

Map entries are now EasyBuild multi-compiler strings, e.g. u74-mc:

`GCC:-march=rva20u64 -mtune=sifive-u74 -mabi=lp64d;Clang:-mcpu=sifive-u74 -mabi=lp64d;LLVM:-mcpu=sifive-u74 -mabi=lp64d`

CI installs `gcc-riscv64-linux-gnu` + `clang` and runs acceptance checks for both toolchains (`EESSI_RISCV_OPTARCH_REQUIRE_COMPILERS=1`). Locally verified: all GCC and Clang/LLVM flag sets compile an empty C unit.

[hugomeiland]

Design note: RISC-V archdetect vs build-time -march/-mtune

This PR does two related but intentionally separate things. That split is the main design point (also answering @julianmorillo / @casparvl about where -march comes from).

The problem with the x86-style path

On x86/ARM, EESSI can usually:

1. set EESSI_SOFTWARE_SUBDIR_OVERRIDE to the target path, and
2. leave EasyBuild optarch unset so the compiler uses host-native flags (-march=native / -mcpu=native).

That fails on RISC-V:

x86/ARM assumption	RISC-V reality
-march=native exists	It does not
Host ≈ EESSI target	Breaks for profiles and cross-target bot jobs
Spec / ISA string ≈ compiler flag	Feature tokens for matching ≠ a -march string
Native implies good tuning	Need explicit -mtune / -mcpu

EasyBuild’s get_isa_riscv() (easybuild-framework#5029) only helps “build on this host for this host”. It does not know about EESSI paths like riscv64/sifive/u74-mc or riscv64/generic/rva22u64.

/proc/cpuinfo isa: is also a poor CPU identity: it varies by vendor, kernel, and board (e.g. same SiFive vendor for P550 vs U74; different X60 ISA strings across kernels). Matching the whole ISA string was brittle; tokenizing it (this PR) fixes detection, but then the spec column is no longer a ready-made -march= value — so builds need another source of flags.

Design: split runtime selection from build-time flags

1. Runtime (archdetect) — eessi_archdetect.sh + eessi_arch_riscv.spec
   Choose the software subdirectory via tokenized ISA features + vendor.
   Includes vendor targets (sifive/u74-mc, sifive/p550, spacemit/x60, …) and profile paths (riscv64/generic/rva20u64, rva22u64, rva23u64).

2. Build time (optarch map) — init/arch_specs/eessi_riscv_optarch.map + init/eessi_riscv_optarch.sh
   Map software_subdir → EASYBUILD_OPTARCH (EasyBuild multi-compiler form: GCC:…;Clang:…;LLVM:…).
   Wired in bot/build.sh and EESSI-install-software.sh (honours pre-set EASYBUILD_OPTARCH / --generic).

Same idea as GPU builds: accel/nvidia/cc80 already maps to an explicit EasyBuild setting; RISC-V CPU targets need the same for -march/-mtune.

Flag roles

• -march = legal instruction set (prefer RISC-V profiles where possible: rva20u64, …)
• -mtune / -mcpu = microarchitecture (e.g. sifive-u74, sifive-p400-series; SpacemiT stays -mtune=generic until toolchains grow a name)
• -mabi=lp64d = keep consistent with the EESSI RISC-V Linux userspace
• GENERIC = EasyBuild’s compatibility floor (-march=rv64gc -mabi=lp64d), not an optimization strategy

Example (u74-mc):

GCC:-march=rva20u64 -mtune=sifive-u74 -mabi=lp64d;Clang:-mcpu=sifive-u74 -mabi=lp64d;LLVM:-mcpu=sifive-u74 -mabi=lp64d

What this PR lands

Piece	Role
Tokenized RISC-V ISA matching	Reliable archdetect
sifive/u74-mc + tests (from #234)	VisionFive 2 / U74 detection
Profile + vendor specs	Runtime paths
eessi_riscv_optarch.map	Build-time flags for GCC + Clang/LLVM
CI for map + compiler acceptance	Guard the mapping

Happy to adjust map entries (especially SpacemiT -march strings) based on review.

[bedroge]

I think it would be better/nicer if this is done by EESSI-extend. That way, both the bot and EESSI users doing builds on top of EESSI will get the right optimization flags when loading EESSI-extend. We sort of do the same for NVIDIA and AMD compute capabilities (https://github.com/EESSI/software-layer-scripts/blob/main/EESSI-extend-easybuild.eb#L216).

[hugomeiland]

Good call — done in d6d5ad1.

RISC-V EASYBUILD_OPTARCH is now set from init/arch_specs/eessi_riscv_optarch.map when loading EESSI-extend (same idea as CUDA/AMD compute capabilities): if EESSI_SOFTWARE_SUBDIR is riscv64/* and EASYBUILD_OPTARCH is not already set (e.g. --generic), the module looks up the map and setenvs it.

Removed the duplicate wiring from bot/build.sh and EESSI-install-software.sh. The shell helper init/eessi_riscv_optarch.sh stays for tests / optional direct use.

So both the bot and users extending EESSI get the mapped -march/-mtune/-mcpu flags via module load EESSI-extend.

[HaoZeke]

The tokenization direction looks right to me and the vendored targets (p550, u74-mc, x60, x60-k6.6) are consistent between spec and map.

The generic profile entries are the problem: I don't think they can match at all under the vendor gate, one has a malformed token, and the specs are weaker than what the map compiles with; details inline.

On scope I'd split the optarch map + EESSI-extend Lua + its CI out, so the archdetect fix can merge while the optarch design gets its own discussion.
The map also has two parsers now, bash and Lua, which will drift.

[HaoZeke]

rv64imafdciv has i twice, and the kernel prints the single-letter block in canonical order (1, "ISA string ordering rules"; the canonical order itself is Appendix C of the ISA manual 2), so /proc/cpuinfo can never produce ...dciv.
Should be rv64imafdcv I think.
Doesn't matter anyway right now because of the vendor gate, but it'll be a silent never-match once that's fixed.

[HaoZeke]

The -march here looks right to me (RVA22U64 implies zba/zbb/zbs/zicbo* 1), but the spec entry for the same subdir only asks for rv64imafdc + zfhmin, so wouldn't a host with zfhmin and no zbs get labeled rva22u64 and receive binaries it can't run?
Might be worth a test that every extension in a subdir's -march is required by its spec line; the vendored targets already pass that, it's only the profile entries.

[HaoZeke]

While the format is open: the leading rv64imafdch blob still matches as one token, so a superset host (say rv64imafdcvh) fails a spec asking rv64imafdch.
Splitting the blob into per-letter tokens would make the base extensions individually matchable, which I think is what the description is going for?
If the expansion happens on both sides at match time, the spec files keep the readable concatenated form, something like

riscv_expand_base(){
    # rv64imafdch -> rv64 i m a f d c h ; every other token passes through
    local out="" tok
    for tok in "$@"; do
        if [ "${tok#rv64}" != "${tok}" ]; then
            out="${out} rv64 $(printf '%s' "${tok#rv64}" | sed 's/./& /g')"
        else
            out="${out} ${tok}"
        fi
    done
    printf '%s' "${out}"
}

# here, for the host flags:
cpu_flags=$(riscv_expand_base ${cpu_flags})

# and at the match, for the spec side:
check_allinfirst "${cpu_flags[*]}" $(riscv_expand_base ${arch_spec[2]})

so a superset host matches any subset spec without the spec files caring how the kernel concatenated the letters.
Also trailing whitespace on this line, and the comment block is tab-indented against the file.

[HaoZeke]

This makes a missing map line fail module load for everyone on that target, including site installs with their own optarch policy.
Maybe warn and fall through to the default like the CUDA capabilities do?

[HaoZeke]

Two things maybe worth a comment in the file: the module versions are pinned, so the next dev.eessi.io rebuild breaks this, and -fsyntax-only never reaches the assembler, so the job name overclaims a bit.
The triple override combo also skips the init scripts' own consistency checks; one line saying it's deliberate would help the next reader.

[HaoZeke]

I don't think these three can ever match?
cpupath() compares vendors first 1 and only aarch64 has an unknown-vendor fallback 2, so everything real gets an mvendorid 3 and an empty vendor field never survives the gate.

I think the riscv64/sifive/u74-mc:riscv64/generic in the u74-mc fixture 5 is also shown that way because of this.
Its isa line 4 tokenizes to

rv64imafdc zicntr zicsr zifencei zihpm zca zcd zba zbb

which contains everything the rva20u64 entry asks for (rv64imafdc, 6), so feature-wise it should have matched.
Separately, the entry is a lot weaker than the actual RVA20U64 profile, which also mandates Zicsr, Zicntr, and Zifencei among others 7; probably fine as a matching heuristic, but worth saying which one it's meant to be.

Maybe add a riscv fallback like the ARM 0x41 one 2, or drop the three entries until that exists?
There's also no generic/rva* fixture right now, so CI can't catch this.