Yeah, I'll take you suggestion and go ahead, Robin's suggestion is great but it's just a little too magic :P
On Wed, Oct 11, 2023 at 4:00 PM 钟居哲 <juzhe.zh...@rivai.ai> wrote: > > Any update of this patch? > > Currently, we are running vect testsuite with -march=rv64gcv_zvl128b > > I am planning to run vect testsuite with these following combinations: > > -march=rv64gcv_zvl128b --param=riscv-autovec-lmul=m1 > -march=rv64gcv_zvl128b --param=riscv-autovec-lmul=m2 > -march=rv64gcv_zvl128b --param=riscv-autovec-lmul=m4 > -march=rv64gcv_zvl128b --param=riscv-autovec-lmul=m8 > -march=rv64gcv_zvl128b --param=riscv-autovec-lmul=dynamic > > -march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m1 > -march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m2 > -march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m4 > -march=rv64gcv_zvl256b --param=riscv-autovec-lmul=m8 > -march=rv64gcv_zvl256b --param=riscv-autovec-lmul=dynamic > > -march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m1 > -march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m2 > -march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m4 > -march=rv64gcv_zvl512b --param=riscv-autovec-lmul=m8 > -march=rv64gcv_zvl512b --param=riscv-autovec-lmul=dynamic > > -march=rv64gcv_zvl1024b --param=riscv-autovec-lmul=m1 > -march=rv64gcv_zvl1024b --param=riscv-autovec-lmul=m2 > -march=rv64gcv_zvl1024b --param=riscv-autovec-lmul=m4 > -march=rv64gcv_zvl1024b --param=riscv-autovec-lmul=m8 > -march=rv64gcv_zvl1024b --param=riscv-autovec-lmul=dynamic > > -march=rv64gcv_zvl2048b --param=riscv-autovec-lmul=m1 > -march=rv64gcv_zvl2048b --param=riscv-autovec-lmul=m2 > -march=rv64gcv_zvl2048b --param=riscv-autovec-lmul=m4 > -march=rv64gcv_zvl2048b --param=riscv-autovec-lmul=m8 > -march=rv64gcv_zvl2048b --param=riscv-autovec-lmul=dynamic > > -march=rv64gcv_zvl4096b --param=riscv-autovec-lmul=m1 > -march=rv64gcv_zvl4096b --param=riscv-autovec-lmul=m2 > -march=rv64gcv_zvl4096b --param=riscv-autovec-lmul=m4 > -march=rv64gcv_zvl4096b --param=riscv-autovec-lmul=m8 > -march=rv64gcv_zvl4096b --param=riscv-autovec-lmul=dynamic > > I will do that in stage 3. I hope this patch can be landed before I do that. > ________________________________ > juzhe.zh...@rivai.ai > > > From: Kito Cheng > Date: 2023-10-05 22:00 > To: Robin Dapp > CC: Jeff Law; gcc-patches; kito.cheng; palmer; 钟居哲 > Subject: Re: [PATCH] RISC-V: Fix the riscv_legitimize_poly_move issue on > targets where the minimal VLEN exceeds 512. > Hi Robin: > > Your suggested code seems work fine, let me run more test and send v2, I > guess I just don’t know how to explain why it work in comment :p > > Robin Dapp <rdapp....@gmail.com>於 2023年10月5日 週四，03:57寫道： >> >> >> I think the "max poly value" is the LMUL 1 mode coeffs[1] >> >> >> >> See int vlenb = BYTES_PER_RISCV_VECTOR.coeffs[1]; >> >> >> >> So I think bump max_power to exact_log2 (64); is not enough. >> >> since we adjust the LMUL 1 mode size according to TARGET_MIN_VLEN. >> >> >> >> I suspect the testcase you append in this patch will fail with >> >> -march=rv64gcv_zvl4096b. >> > >> > >> > There is no type smaller than [64, 64] in zvl4096b, RVVMF64BI is [64, >> > 64], it’s smallest type, and RVVFM1BI is [512, 512] (size of single >> > vector reg.) which at most 64x for zvl4096b, so my understanding is >> > log2(64) is enough :) >> > >> > and of cause, verified the testcase is work with -march=rv64gcv_zvl4096b >> >> I was wondering if the whole hunk couldn't be condensed into something >> like (untested): >> >> div_factor = wi::ctz (factor) - wi::ctz (vlenb); >> if (div_factor >= 0) >> div_factor = 1; >> else >> div_factor = 1 << -div_factor; >> >> This would avoid the loop as well. An assert for the div_factor (not >> exceeding a value) could still be added. >> >> Regards >> Robin
