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
