Re: [PATCH] RISC-V: Add Ascalon XG cpu support

On 8/12/2026 1:04 PM, Peter Bergner wrote:
> This adds support for the global version of Ascalon X (tt-ascalon-xg)
> to the list of known cores.  The difference between Ascalon X & XG is XG
> does not have the zvkng extension and it has reduced vector FP64 throughput.
>
> Notes on my implementation: I decided against renaming tt_ascalon_d8 to
> tt_ascalon_x as I thought that was too much churn for little benefit.  Given the
> huge similarity between the X and XG, I used the same tt_ascalon_d8 automaton
> for both cores, just redirecting XG's FP64 vector ops into a new non-pipelined
> unit to reduce their throughput.
>
> Regtested on rv64gcv-linux with no regressions.
> Ok for trunk?
>
> I'd eventually like to backport this too.  Ok for backports once it has
> baked on trunk for a while?
>
> Peter
>
>
>
> 2026-08-12  Peter Bergner  <[email protected]>
>
> gcc/
> 	* config/riscv/riscv-cores.def (RISCV_TUNE): Add tt-ascalon-xg.
> 	(RISCV_CORE): Likewise.
> 	* config/riscv/riscv-opts.h (enum riscv_microarchitecture_type):
> 	Add tt_ascalon_xg.
> 	* config/riscv/riscv.md (tune): Likewise.
> 	* config/riscv/tt-ascalon-d8.md (asc-xg-fp64-vec0, asc-xg-fp64-vec1):
> 	New define_cpu_unit.
> 	(tt_ascalon_xg_fp64_vec): New define_reservation.
> 	(tt_ascalon_d8_int_load, tt_ascalon_d8_alu, tt_ascalon_d8_sfb,
> 	tt_ascalon_d8_branch, tt_ascalon_d8_float_move, tt_ascalon_d8_fcvt,
> 	tt_ascalon_d8_fcmp, tt_ascalon_d8_imul, tt_ascalon_d8_idiv,
> 	tt_ascalon_d8_fadd, tt_ascalon_d8_mul, tt_ascalon_d8_float_fma,
> 	tt_ascalon_d8_float_div_half, tt_ascalon_d8_float_div_single,
> 	tt_ascalon_d8_float_div_double, tt_ascalon_d8_popcount,
> 	tt_ascalon_d8_vec_load, tt_ascalon_d8_vec_store,
> 	tt_ascalon_d8_vec_load_strided, tt_ascalon_d8_vec_store_strided,
> 	tt_ascalon_d8_vec_load_indexed, tt_ascalon_d8_vec_store_indexed,
> 	tt_ascalon_d8_vec_loadstore_seg, tt_ascalon_d8_vec_alu_1,
> 	tt_ascalon_d8_vec_alu_2, tt_ascalon_d8_vec_alu_3,
> 	tt_ascalon_d8_vec_alu_4, tt_ascalon_d8_vec_imul, tt_ascalon_d8_vec_pop,
> 	tt_ascalon_d8_vec_crypto_aes, tt_ascalon_d8_vec_crypto_sha,
> 	tt_ascalon_d8_vec_perm_1, tt_ascalon_d8_vec_perm_3,
> 	tt_ascalon_d8_vec_perm_4, tt_ascalon_d8_vec_reduction,
> 	tt_ascalon_d8_vec_ordered_reduction, tt_ascalon_d8_vec_idiv_byte,
> 	tt_ascalon_d8_vec_idiv_half, tt_ascalon_d8_vec_idiv_single,
> 	tt_ascalon_d8_vec_idiv_double, tt_ascalon_d8_vec_float_divsqrt_half,
> 	tt_ascalon_d8_vec_float_divsqrt_single,
> 	tt_ascalon_d8_vec_float_divsqrt_double, tt_ascalon_d8_vec_mask,
> 	tt_ascalon_d8_vec_vesetvl, tt_ascalon_d8_vec_setrm,
> 	tt_ascalon_d8_vec_readlen, tt_ascalon_d8_vec_unknown):
> 	Use tt_ascalon_xg.
> 	(tt_ascalon_d8_vec_fcmp, tt_ascalon_d8_vec_fadd,
> 	tt_ascalon_d8_vec_fmul): Disable vector instructions that produce FP64
> 	output values when tuning for tt_ascalon_xg.
> 	(tt_ascalon_xg_fp64_vec_insns): New define_insn_reservation.
> 	* doc/riscv-mcpu.texi: Regenerate.
> 	* doc/riscv-mtune.texi: Likewise.
GIven this all specific to the ascalon cores, I'd say you (or your team) 
ought to be able to adjust these at-will and push them.  I'm not going 
to second guess this stuff as you know the uarch while I know nothing 
about the uarch ;-)

As for backporting.  I'm guessing the real benefit is just having the 
tt-ascalon-xg name recognized across releases.  But again, given it's 
all tuning stuff for the ascalon cores, if you want to backport, go for 
it.  Just give a little soak time on the trunk first (not that I'd 
expect anything weird from a change like this, but stranger things have 
happened).

jeff