On 6/4/25 10:36, Jeff Law wrote: > 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.
The update is NFC, just to the commit log to attribute this to fixing PR119164 and adding the corresponding test. > 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. Thx, -Vineet
