Thanks Robin. Let me share one example for the CALL scenario, considering below 
code.

external int fesetround(int rounding_mode);

test_call_for_rm:
                                                 <-        FRM X
   vfadd RTZ (static)               <-        FRM RTZ
                                                 <-        RESTORE FRM X
   call fesetround RMM         <-        Change FRM to RMM during the call
                                                 <-        Backup the FRM RMM
   vfadd RUP (static)              <-         FRM RUP
                                                 <-         Restore the FRM to 
RMM
   ret

When emit at the insn call, we need to emit 2 insns, one restore before the 
call and one backup after call, to ensure 2 things.

1. The static FRM should not pollute the call.
2. The updated FRM in the call will alive to the end of the cfun.

Unfortunately, current mode switching cannot emit 2 insns as above, it mostly 
emits after. It become even worse when the call
is the last insn of the bb, we try to do some special handling in needed 
function for this.

And thank robin again for nits and cleanups, like 
previous/next_nonnote_nondebug_insn_bb.

Pan

-----Original Message-----
From: Robin Dapp <rdapp....@gmail.com> 
Sent: Tuesday, July 25, 2023 4:38 PM
To: Li, Pan2 <pan2...@intel.com>; gcc-patches@gcc.gnu.org
Cc: rdapp....@gmail.com; juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang, 
Yanzhang <yanzhang.w...@intel.com>
Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic 
rounding

Hi Pan,

> Given we have a call, we would like to restore before call and then
> backup frm after call. Looks current mode switching cannot emit insn
> like that, it can only either emit insn before (mostly) or after
> (when NOTE_INSN_BASIC_BLOCK_P). Thus, we try to emit the one after
> call when needed as a specially handling here.

Would you mind explaining a bit more here?  As far as I know we can
perform necessary mode switching (including saving necessary
registers) directly after function entry and right before function
exit.  Is this somehow too early or too late or cannot handle what
you want?

The patch in itself makes sense (apart from some nits and possible
cleanups) but I'm still missing the bigger picture.  For me it gets
more confusing with every patch to be honest :D

Regards
 Robin

Reply via email to