Hi Pan:
Thanks for your effort on this, this is LGTM and OK for trunk. Hi Robin: Thanks for your review on this stuff, this set of intrinsic functions is complicated and might be controversial since the whole floating point rounding mode is…complicated, and people might have different tastes on that. So what we (RVV intrinsic TG) trying to do is adding another set of intrinsic *and* keep existing floating point intrinsic, so people could still using fesetround style to play around the floating point stuffs, but I am not intend to convince you that is necessary and it's 100% right design - I admit it's kind of experimental design as the LLVM's constrained floating-point intrinsics. Anyway, let's move forward, and see how useful it is for the RISC-V ecosystem :) On Fri, Jul 28, 2023 at 8:35 PM Li, Pan2 via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > Great! Thanks Robin for so many useful comments, as well as the > thought-provoking discussion with different insights. > I believe such kind of interactively discussion will empower all of us, and > leading us to do the right things. > > Back to this PATCH, I try to only do one thing at a time and I totally agree > that there are something we need to try. > Thanks again and let's wait for kito's comments. > > Pan > > -----Original Message----- > From: Robin Dapp <rdapp....@gmail.com> > Sent: Friday, July 28, 2023 6:05 PM > To: Li, Pan2 <pan2...@intel.com>; gcc-patches@gcc.gnu.org > Cc: rdapp....@gmail.com; juzhe.zh...@rivai.ai; kito.ch...@sifive.com; Wang, > Yanzhang <yanzhang.w...@intel.com> > Subject: Re: [PATCH v8] RISC-V: Support CALL for RVV floating-point dynamic > rounding > > 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
