You mean this patch is ok?
juzhe.zh...@rivai.ai From: Jeff Law Date: 2023-09-15 23:27 To: 钟居哲; kito.cheng CC: gcc-patches; kito.cheng; rdapp.gcc Subject: Re: [PATCH V4] RISC-V: Expand VLS mode to scalar mode move[PR111391] On 9/14/23 16:26, 钟居哲 wrote: > I don't think it can fix the case when it is -march=rv64gc_zve32x > > ------------------------------------------------------------------------ > juzhe.zh...@rivai.ai > > *From:* Kito Cheng <mailto:kito.ch...@gmail.com> > *Date:* 2023-09-15 00:17 > *To:* Juzhe-Zhong <mailto:juzhe.zh...@rivai.ai> > *CC:* gcc-patches <mailto:gcc-patches@gcc.gnu.org>; kito.cheng > <mailto:kito.ch...@sifive.com>; jeffreyalaw > <mailto:jeffreya...@gmail.com>; rdapp.gcc <mailto:rdapp....@gmail.com> > *Subject:* Re: [PATCH V4] RISC-V: Expand VLS mode to scalar mode > move[PR111391] > I am thinking what we are doing is something like we are allowing > scalar mode within the vector register, so...not sure should we try to > implement that within the mov pattern? > I guess we need some inputs from Jeff. It's advantageous if we can avoid it. It often gets quite ugly when you start allowing something like scalar modes in vector registers -- particularly if you support something other than simple moves. But we may end up needing to do that anyway to do something like supporting the sqrt & recip estimators in scalar FP modes, which can be very advantageous for benchmarks like nab. So my suggestion would be go ahead if it looks like it can really solve this problem -- knowing there will likely be a long tail of fallout. If it doesn't help pr111391, then let's defer until we really dive into 544.nab/644.nab and try to improve that sqrt (x) and 1/sqrt(x) sequence that shows up in there. jeff
