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

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

> I would like to propose that being focus and moving forward for this
> patch itself, the underlying other RVV floating point API support and
> the RVV instrinsic API fully tests depend on this.

Sorry, I didn't mean to ditch LCM/mode switching.  I believe it is doing
a pretty good job and we should continue to use it.  The changes in this
patch (and the ones before) seem to follow a certain plan but, at least
to me, it only became obvious with this last patch.  We're already lost
in details when the fundamentals are not agreed upon yet.  It would have
been easier to discuss (and quicker to "focus and move forward") if the
cover letter had already laid out the possible alternatives and their
respective pros and cons instead, even more so when many things depend
on it.

Still, three things:
 
 (1) I'm fully on board with restoring the rounding mode after changing
 it implicitly via an intrinsic (guess everybody is).  This needs to be
 done anyway and also implies a costly fsrm.  "Forcing" it before a call
 can most likely be treated like any other DYN instruction requiring the
 "entry" rounding mode.  Likewise restoring at function exit.  The
 placement of the necessary restores LCM can handle reasonably well.

 (2) What I'm not entirely happy with is assuming that every function
 call can _change_ the rounding mode and we always need to re-backup it.
 I realize that it might be a necessary evil because all other options
 are worse.  Assuming no change through a call makes properly using
 fesetround-like calls impossible as they would clobber our backup
 register.  This patch takes the approach to re-backup after every call.
 As-is, wouldn't we also need to make sure that GCC  knows that a call
 clobbers the FRM (via clobber: (reg:SI 69 frm)) so we don't accidentally
 move something beyond it?

 (3) One other option I can think of is "localized" re-backup of the
 FRM before each mode-changing intrinsic.  That would result in
 redundant save/restore insns around those than with the call proposal
 and therefore likely worse.  Whether that is relevant when the restore
 is slow anyway might be debatable.  Yet, it's not a given that storing
 the FRM always is an in-order operation, it has just mostly been
 that way historically.  Another conceivable option (and maybe even
 the right thing to do) would be special treatment, like a propagating
 flag etc. for fesetround.  That's common code and not likely to happen
 or land soon, though.

Regards
 Robin