On 5/9/25 2:27 PM, Vineet Gupta wrote:
FRM mode switching state machine has DYN as default state which it also
fallsback to after transitioning to other states such as DYN_CALL.
Currently TARGET_MODE_EMIT generates a FRM restore on any transition to
DYN leading to spurious/extraneous FRM restores.
Only do this if an interim static Rounding Mode was observed in the state
machine.
This reduces the number of FRM writes in SPEC2017 -Ofast -mrv64gcv build
significantly.
Before After
------------- -------------
frrm fsrmi fsrm frrm fsrmi frrm
perlbench_r 42 0 4 17 0 1
cpugcc_r 167 0 17 11 0 0
bwaves_r 16 0 1 16 0 1
mcf_r 11 0 0 11 0 0
cactusBSSN_r 76 0 27 19 0 1
namd_r 119 0 63 14 0 1
parest_r 168 0 114 24 0 1
povray_r 123 1 17 26 1 6
lbm_r 6 0 0 6 0 0
omnetpp_r 17 0 1 17 0 1
wrf_r 2287 13 1956 1268 13 1603
cpuxalan_r 17 0 1 17 0 1
ldecod_r 11 0 0 11 0 0
x264_r 14 0 1 11 0 0
blender_r 724 12 182 61 12 42
cam4_r 324 13 169 45 13 20
deepsjeng_r 11 0 0 11 0 0
imagick_r 265 16 34 132 16 25
leela_r 12 0 0 12 0 0
nab_r 13 0 1 13 0 1
exchange2_r 16 0 1 16 0 1
fotonik3d_r 20 0 11 19 0 1
roms_r 33 0 23 21 0 1
xz_r 6 0 0 6 0 0
--------------- --------------
4498 55 2623 1804 55 1707
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_emit_frm_mode_set): check
STATIC_FRM_P for trnsition to DYN.
So per the patchwork call earlier this week I know you've got an update
in flight. Even so, this looks correct to me. I'm likely
over-simplifying, but essentially if we don't have some static setting
of FRM, then there's no need to bother with a restore -- which seems
corect to me.
Jeff
