OK, you can go ahead commit patch.
I am gonna send another patch to fix this.
Besides, I saw you have commit some redundant incorrect codes, I will clean
them up in another patch.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-05-07 04:11
To: juzhe.zh...@rivai.ai; Robin Dapp; gcc-patches; kito.cheng; Kito.cheng;
palmer; collison
Subject: Re: [PATCH] riscv: Allow vector constants in riscv_const_insns.
On 5/3/23 23:07, juzhe.zh...@rivai.ai wrote:
> This ideal of this patch looks good to me.
> But I think this patch should be able to handle more cases (not only -16
> ~ 15) in case of CONST_VECTOR initialization.
>
> Case 1 (Other constant value that is not -16 ~ 15):
> void vmv_m##VAL (TYPE dst[], int n) \
> { \
> for (int i = 0; i < n; i++) \
> dst[i] = 100; \
> }
>
> I guess for const_vector:100 is not optimal currently so far, I think
> you may try (and add testcases).
> Such code can be:
>
> Codegen 1: Codegen 2:
> li a5,100 vlse.v v24, (a5), zero ;; a5
> address memory has the value of 100.
> vmv.v.x v1, a5
>
> I am not sure codegen 1 or codegen 2, which one is better. I think you
> can decide it.
> But my idea is that I think this patch should not only handle he
> constant value of -16 ~ 15, but also other constant value should be
> handled and tested in this patch.
>
> Case 2 (Constant value *within 32bit* for INT64 in *RV32* system):
>
> This is a special case:
>
> void vmv_i64 (TYPE dst[], int n)
> {
> for (int i = 0; i < n; i++)
> dst[i] = *0xAAAAAAAA*;
> }
>
> In this case, the Codegen should be similiar with Case 1 since each
> scalar register can hold the whole constant value.
>
>
> Case 3 (Constant value over* 32bit* for INT64 in *RV32* system):
>
> This is a special case:
>
> void vmv_i64 (TYPE dst[], int n)
> {
> for (int i = 0; i < n; i++)
> dst[i] = *0xAAAAAAAAA*;
> }
>
> In this case, since each scalar register can only hold 32bit value that
> is not the whole constant value (*0xAAAAAAAAA)*
> I think in this case, we can only use vlse.v...
>
> Would you refine this patch more? Thanks.
I think we can add those as distinct patches. The [-16..15] change is
simple, stands on its own and I don't see any strong reason to make it
wait for handling additional cases.
Remember, there are multiple engineers working in this space now. So
things which are clearly correct should move forward quickly so that we
don't end up duplicating work.
Handling the additional cases can be handled as a distinct patch on its
own.
Jeff
