[Bug target/115795] RISC-V: vsetvl step causes wrong codegen after fusing info
juzhe.zhong at rivai dot ai
gcc-bugzilla@gcc.gnu.org
Mon Jul 8 22:10:46 GMT 2024
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795
--- Comment #7 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to Jordi Sala from comment #6)
> Perfect, that's what I was looking for. I'm thinking of adding a way to tell
> GCC to minimize, maximize or preserve SEW on vsetvl expand. Like
> -mrvv-vsetvl-sew={maximize,minimize,preserve}
No. I don't think you need to add an option here.
I think you should change the default according to the vsetvl intrinsic builtin
sematic. For example, set SEW/LMUL as e32m2 if it is __riscv_vsetvl_e32m2, or
set it as e64m1 if it is __riscv_vsetvl_e64m1 which will make codegen more
straightforward.
if (TARGET_XTHEADVECTOR)
{
machine_mode inner_mode = GET_MODE_INNER (mode);
/* SEW. */
e.add_input_operand (Pmode,
gen_int_mode (GET_MODE_BITSIZE (inner_mode), Pmode));
/* LMUL. */
e.add_input_operand (Pmode,
gen_int_mode (get_vlmul (mode), Pmode));
}
else
{
/* Normalize same RATO (SEW/LMUL) into same vsetvl instruction.
- e8,mf8/e16,mf4/e32,mf2/e64,m1 --> e8mf8
- e8,mf4/e16,mf2/e32,m1/e64,m2 --> e8mf4
- e8,mf2/e16,m1/e32,m2/e64,m4 --> e8mf2
- e8,m1/e16,m2/e32,m4/e64,m8 --> e8m1
- e8,m2/e16,m4/e32,m8 --> e8m2
- e8,m4/e16,m8 --> e8m4
- e8,m8 --> e8m8
*/
/* SEW. */
e.add_input_operand (Pmode, gen_int_mode (8, Pmode));
/* LMUL. */
machine_mode e8_mode
= get_vector_mode (QImode, GET_MODE_NUNITS (mode)).require ();
e.add_input_operand (Pmode, gen_int_mode (get_vlmul (e8_mode), Pmode));
}
into:
machine_mode inner_mode = GET_MODE_INNER (mode);
/* SEW. */
e.add_input_operand (Pmode,
gen_int_mode (GET_MODE_BITSIZE (inner_mode), Pmode));
/* LMUL. */
e.add_input_operand (Pmode,
gen_int_mode (get_vlmul (mode), Pmode));
More information about the Gcc-bugs
mailing list