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

["Li, Pan2" <pan2.li@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]

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: 钟居哲 <juzhe.zhong@rivai.ai>
Sent: Wednesday, July 26, 2023 10:18 PM
To: rdapp.gcc <rdapp.gcc@gmail.com>; Li, Pan2 <pan2.li@intel.com>
Cc: rdapp.gcc <rdapp.gcc@gmail.com>; kito.cheng <kito.cheng@sifive.com>; gcc-patches <gcc-patches@gcc.gnu.org>; Wang, Yanzhang <yanzhang.wang@intel.com>
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<mailto:juzhe.zhong@rivai.ai>

From: Robin Dapp<mailto:rdapp.gcc@gmail.com>
Date: 2023-07-26 21:46
To: juzhe.zhong<mailto:juzhe.zhong@rivai.ai>; Li, Pan2<mailto:pan2.li@intel.com>
CC: rdapp.gcc<mailto:rdapp.gcc@gmail.com>; Kito Cheng<mailto:kito.cheng@sifive.com>; gcc-patches@gcc.gnu.org<mailto:gcc-patches@gcc.gnu.org>; Wang, Yanzhang<mailto:yanzhang.wang@intel.com>
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