bne a1,zero,.L3
ret
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-20 16:24
To: juzhe.zh...@rivai.ai
CC: Robin Dapp; gcc-patches; kito.cheng; jeffreyalaw
Subject: Re: Re: [PATCH] RISC-V: Support in-order floating-point reduction
reduction_type = reduction_type::UNORDERED
On Thu, Jul 20
> CC: Robin Dapp; gcc-patches; kito.cheng; jeffreyalaw
> Subject: Re: Re: [PATCH] RISC-V: Support in-order floating-point reduction
> Seems like because you ` using namespace riscv_vector;` so the
> UNORDERED in expand_vec_cmp_float used reduction_type::UNORDERED
>
> Hmmm, maybe
16:03
To: juzhe.zh...@rivai.ai
CC: Robin Dapp; gcc-patches; kito.cheng; jeffreyalaw
Subject: Re: Re: [PATCH] RISC-V: Support in-order floating-point reduction
Seems like because you ` using namespace riscv_vector;` so the
UNORDERED in expand_vec_cmp_float used reduction_type::UNORDERED
Hmmm
Seems like because you ` using namespace riscv_vector;` so the
UNORDERED in expand_vec_cmp_float used reduction_type::UNORDERED
Hmmm, maybe enum class?
enum class reduction_type
{
UNORDERED,
FOLD_LEFT,
MASK_LEN_FOLD_LEFT,
};
and need use like this reduction_type::UNORDERED
On Thu, Jul 20,
I have no ideal, just ICE comes when running regression:
during RTL pass: expand
auto.c: In function 'test_int32_t_float_unordered_var':
auto.c:24:3: internal compiler error: in expand_vec_cmp_float, at
config/riscv/riscv-v.cc:2564
24 | test_##TYPE1##_##TYPE2##_##CMP##_var (TYPE1 *restrict d
Oh, Yes.
It can be easily addressed by this:
emit_scalar_move_insn (code_for_pred_broadcast (m1_mode), scalar_move_ops);
This patch emit scalar move insn with AVL = 1 for all reduction. It can easily
addressed when we recognize it is mask_len_fold_left_plus reduction,
we assign the AVL to the sc
The UNORDERED enum will cause ICE since we have UNORDERED in rtx_code.
Could you give me another enum name?
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-20 15:41
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Support in-orde
