As Juzhe mentioned, the problem of the CALL is resolved by LCM/PRE similar to the VSETVL pass, which is well proofed up to a point. 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. Of course, I am working on PATCH v8 and thanks again for Robin’s comments. Pan From: 钟居哲 Sent: Wednesday, July 26, 2023 10:18 PM To: rdapp.gcc ; Li, Pan2 Cc: rdapp.gcc ; kito.cheng ; gcc-patches ; Wang, Yanzhang Subject: Re: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic rounding Explicitly backup and restore for each intrinsic just the same as we did for CALL in this patch. I can't have the data to prove how good we use LCM/PRE of mode switching but I trust it. Since the the LCM/PRE is the key optimization method of VSETVL PASS which is doing good job on VSETVL instruction optimizations. I don't we should give up LCM/PRE chance then just backup and restore for each intrinsic bindly. ________________________________ juzhe.zhong@rivai.ai From: Robin Dapp Date: 2023-07-26 21:46 To: juzhe.zhong; Li, Pan2 CC: rdapp.gcc; Kito Cheng; gcc-patches@gcc.gnu.org; Wang, Yanzhang Subject: Re: [PATCH v7] RISC-V: Support CALL for RVV floating-point dynamic rounding > current llvm didn't do any pre optimization. They always > backup+restore for each rounding mode intrinsic I see. There is still the option of lazily restoring the (entry) FRM before a function call but not read the FRM after every call. Do we have any data on how good or bad the mode-switching LCM works when we explicitly backup and restore for each intrinsic? Regards Robin