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 <[email protected]>
Sent: Tuesday, July 25, 2023 4:38 PM
To: Li, Pan2 <[email protected]>; [email protected]
Cc: [email protected]; [email protected]; [email protected]; Wang,
Yanzhang <[email protected]>
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