Re: [PATCH v8] RISC-V: Support CALL for RVV floating-point dynamic rounding

[Robin Dapp <rdapp.gcc@gmail.com>]

Hi Pan,

thanks for your patience and your work.  Apart from my general doubt
whether mode-changing intrinsics are a good idea, I don't have other
remarks that need fixing.  What I mentioned before:

 - Handling of asms wouldn't be a huge change.  It can be done
 in a follow-up patch of course but should be done eventually.

 - The code is still rather difficult to follow because we diverge
 from the usual mode-switching semantics e.g. in that we emit insns
 in mode_needed as well as in mode_set.  I would have preferred
 to stay close to the regular usage, document where and why we need
 to do something different and suggest future middle-end improvements
 to solve this more elegantly.

 - I hope non-local control flow like setjmp/longjmp, sibcall
 optimization and maybe others work fine.  I didn't see a reason
 why not but I haven't checked very closely either.

 - We can probably get away with not annotating every call with
 an FRM clobber because there isn't any pass that would make use
 of that anyway?


As to my general qualm, independent of this patch, quickly
summarized again one last time (the problem was latent before this
specific patch anyway):

I would prefer not to have mode-changing intrinsics at all but
have users call fesetround explicitly.  That way the exact point
where the rounding mode is changed would be obvious and not
subject to optimization as well as caching/backing up.
If at all necessary I would have preferred the LLVM way of
backing up, setting new mode, performing the instruction
and restoring directly after.
If the initial intent of mode-changing intrinsics was to give
users more control, I don't believe we achieve this by the "lazy"
restore mechanism which is rather an obfuscation.

Pardon my frankness but the whole mode-changing thing feels to me
like just getting a feature out of the door to solve "something"
/appease users than a well thought-out feature.  It doesn't even
seem clear if this optimization is worthwhile when changing the
rounding mode is prohibitively slow anyway.

That said, if the current status is what the majority of
contributors can live with, I'm not going to stand in the way,
but I'd ask Kito or somebody else to give the final OK.

Regards
 Robin