On 8/23/23 08:54, Li, Pan2 wrote:
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.
OK, but I'm still strugging to see how the distinction is important
here. Ultimately there's a state at a call site. We need to make sure
that state from the current function doesn't impact the callee and we
need to make sure that the callee doesn't impact the state in the caller.
That implies a save/restore pair around the call (possibly optimized so
that we minimize the number of save/restores). I would have expected
x86 to already be doing this. But maybe there's some ABI thing around
mmx vs x86 state that allows it to be avoided....
For the rest part, will have a try based on your suggestion soon as I am in the
middle of something.
No problem. Get to it when you can. I think it affects you more than
me :-)
jeff
