Since the C908 core does not support the vector extension, I thought those types did not need to be covered by this model.
I will fix this and send a v2. Milan ________________________________ From: Jeffrey Law <[email protected]> Sent: Wednesday, June 3, 2026 3:24 PM To: Milan Tripkovic <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: Dusan Stojkovic <[email protected]> Subject: Re: [PATCH] RISC-V: Add XuanTie C908 tuning and scheduler model On 6/3/2026 6:26 AM, Milan Tripkovic wrote: > Add tuning definitions for the XuanTie C908 core, including a > scalar scheduler model. > > The scheduler model describes the scalar integer, load/store, multiply, > divide, and floating-point pipeline resources. It is based on the > XuanTie C908 R1S0 User Manual. > > This patch only models scalar scheduling. Vector scheduling is left for > future work (xt-c908v). > > The scheduler model was tested on a CanMV-K230-V1.1 with CoreMark and a set > of instruction throughput tests. > > The instruction throughput tests are essentially unrolled loops which > have groups of instructions (a group of adds and a group of fadd instructions > we are measuring for example) which use independent registers. For the > purpose of estimating the efficiency of scheduling such an unrolled loop, > the impact of reducing pipeline stalls on measured cycle counts is noticeable. > > Each test uses aligned memory access. Before taking > measurements, the benchmark performs 20 warm-up runs. The measured test > is then executed 200 times. > > On a CanMV-K230-V1.1 board, this tuning gives about a 0.8% CoreMark > improvement. > The instruction throughput tests show cycle-count improvements of > about 5% to 17%. > > Long-latency reservations are clamped to 7 cycles, following the existing > RISC-V scheduler modelling approach introduced by commit 8265192. > > 2026-06-03 Milan Tripkovic <[email protected]> > > gcc/ChangeLog: > > * config/riscv/riscv-cores.def (RISCV_TUNE): Changed xt-c908 > PIPELINE_MODEL and TUNE_INFO > * config/riscv/riscv-opts.h (enum riscv_microarchitecture_type): Add > entry > for xt-c908 design > * config/riscv/riscv.cc: New tune structure > for the xt-c908 design. > * config/riscv/riscv.md: Add xt-c908 . > Include xt-c908.md. > * config/riscv/xt-c908.md: New file. So the RISC-V backend enforces the invariant that every insn must map to an insn reservation. Failure to adhere to that invariant will trigger an ICE during scheduling. In practice this means you have to include every insn type in your scheduler model -- even types which would not normally be used. I suspect many insn types are missing from this model. The "pipeline-checker" script in the riscv config directory can help identify cases where you're missing a type. For types which do not make sense on the c908 design just create a dummy insn reservation. Here's what the spacemit-x60 dummy looks like: > (define_insn_reservation "spacemit_x60_dummy" 1 > (and (eq_attr "tune" "spacemit_x60") > (eq_attr "type" "vaesef, > vsha2cl,vsha2ch,vaesz,vclmulh,vghsh,vaeskf1,vaesdm,vgmul, > vaesem,vaesdf,ghost,vsm3me,sf_vc_se,vsm3c, > vaeskf2,vsha2ms,vector,wrvxrm, > vclmul,rdfrm,wrfrm,sf_vc,vsm4k,vsm4r")) > "nothing") With an appropriate dummy reservation this will be OK for the trunk. jeff CONFIDENTIALITY: The contents of this e-mail are confidential and intended only for the above addressee(s). If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, copying or delivering it to anyone else or using it in any unauthorized manner is prohibited and may be unlawful. If you receive this e-mail by mistake, please notify the sender and the systems administrator at [email protected] immediately.
