> 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
