On 10/12/26 7:41 AM, Dusan Stojkovic wrote:
Based on micro-architectural testing of Spacemit-X60 ALU instructions they reserve only one of the two ALU units available on the CPU. Modeling the reservation of ALU instructions as ALU0 or ALU1 moves the needle slightly. Benchmark of coremark executed with perf: taskset -c 0 perf stat -r 10 -e cycles,instructions ./coremark.exe -mtune=spacemit-x60 -march=rv64gc_zba_zbb_zbs -O2 current new cycles 29,442,732,143 +-0.11% 28,892,288,831 +-0.07% insns 31,451,155,580 +-0.03% 31,450,458,048 +-0.03% IPC 1.07 1.09 time (s) 18.4061 +-0.0209 18.0631 +-0.0131 -mcpu=spacemit-x60 -O2 current new cycles 29,715,461,331 +-0.11% 29,622,701,777 +-0.10% insns 29,679,069,220 +-0.03% 29,678,356,566 +-0.03% IPC 1.00 1.00 time (s) 18.5767 +-0.0203 18.5192 +-0.0191 -mcpu=spacemit-x60 -O2 -funroll-loops current new cycles 28,212,445,245 +-0.12% 27,933,417,579 +-0.07% Insns 29,604,622,477 +-0.03% 29,596,231,318 +-0.02% IPC 1.05 1.06 time (s) 17.6383 +-0.0206 17.4639 +-0.0113 As one would expect, the greatest impact of this change is with the vector instructions removed from the -march parameter. Once loop unrolling is included along with vector instructions, this gives extra scalar instructions for the scheduler to move around and the impact of the change is more apparent. 2026-10-12 Dusan Stojkovic <[email protected]> gcc/ChangeLog: config/riscv/spacemit-x60.md (spacemit_x60_alu0, spacemit_x60_alu1): ((spacemit_x60_alu0|spacemit_x60_alu1)): update ALU reservation definition.
I've pushed this to the trunk (cleaning up for patchwork meeting :-) jeff
