Thanks Jeff for comments. > Understood. So the natural question is why does x86/sh not need this > for its mode switching? Don't all the same issues exist on those > targets as well?
AFAIK, it comes from the different design principle between the risc-v and x86/arm intrinsic API. The risc-v rvv FP rounding mode intrinsic API has one abstract level above the insn itself, while the x86/arm only indicates the semantics of the insn. For example, if one vector instruction VFADD doesn't have static rounding mode (aka encoding rm in insn), there is no such a intrinsic API contains rounding mode argument in x86/arm. While the risc-v fp vector intrinsic will always have static rounding mode API if the frm is honored. In short, the risc-v intrinsic API is closer to the end-user, while the x86/arm instrinsic API is closer to insn itself. For the rest part, will have a try based on your suggestion soon as I am in the middle of something. Pan -----Original Message----- From: Jeff Law <jeffreya...@gmail.com> Sent: Wednesday, August 23, 2023 10:25 PM To: Li, Pan2 <pan2...@intel.com>; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; Wang, Yanzhang <yanzhang.w...@intel.com>; kito.ch...@gmail.com Subject: Re: [PATCH v1] Mode-Switching: Add optional EMIT_AFTER hook On 8/23/23 00:03, Li, Pan2 wrote: > Thanks Jeff for comments, and sorry for late response. > > The background comes from the CALL insn. For the RISC-V dynamic rounding mode > we need to > > 1. restore the frm BEFORE call, to avoid the static rounding mode pollute the > call. > 2. Backup the frm AFTER call, to ensure the frm value after call is live. > > Currently, we don’t take care of it elegantly but we would like to refine > this part by the optional EMIT_AFTER. Understood. So the natural question is why does x86/sh not need this for its mode switching? Don't all the same issues exist on those targets as well? > >> I'm not aware of a case where we can have an insn with control flow that >> isn't the end of the block. So perhaps then that second conditional >> into an assertion inside the true arm? > > Not very sure my understanding is correct, but there may be a call insn in > the middle of the bb, > And can be considered as control flow? In the case where the call is control flow, then it'll end the block. Examples of this would be if the call could throw or perform a nonlocal goto. For "normal" calls, they are not considered control flow and can show up in the middle of a block. > >> Is this really correct for EDGE_ABNORMAL? If the abnormal edge is >> created by, say a nonlocal goto, exception handling, etc, then the insn >> you insert at the end of the block will never be executed. > > Got it, let me have a try for this, as well as there is somewhere take care > of this already. You might also peek at the RTL gcse/pre code which is also LCM based and has the same class of problems. jeff
