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
