[PATCH qemu 1/9] target/riscv: rvv: Add mask agnostic for vv instructions

~eopxd posted 9 patches 3 years, 9 months ago
There is a newer version of this series
[PATCH qemu 1/9] target/riscv: rvv: Add mask agnostic for vv instructions
Posted by ~eopxd 3 years, 10 months ago
From: Yueh-Ting (eop) Chen <eop.chen@sifive.com>

This is the first commit regarding the mask agnostic behavior.
Added option 'rvv_ma_all_1s' to enable the behavior, the option
is default to false.

Signed-off-by: eop Chen <eop.chen@sifive.com>
Reviewed-by: Frank Chang <frank.chang@sifive.com>
---
 target/riscv/cpu.c                      | 1 +
 target/riscv/cpu.h                      | 2 ++
 target/riscv/cpu_helper.c               | 2 ++
 target/riscv/insn_trans/trans_rvv.c.inc | 3 +++
 target/riscv/internals.h                | 5 +++--
 target/riscv/translate.c                | 2 ++
 target/riscv/vector_helper.c            | 8 ++++++++
 7 files changed, 21 insertions(+), 2 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index cd4cf4b41e..2bf862a5e4 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -811,6 +811,7 @@ static Property riscv_cpu_properties[] = {
 
     DEFINE_PROP_UINT64("resetvec", RISCVCPU, cfg.resetvec, DEFAULT_RSTVEC),
     DEFINE_PROP_BOOL("rvv_ta_all_1s", RISCVCPU, cfg.rvv_ta_all_1s, false),
+    DEFINE_PROP_BOOL("rvv_ma_all_1s", RISCVCPU, cfg.rvv_ma_all_1s, false),
     DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 8c4a79b5a0..c76ded515b 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -370,6 +370,7 @@ struct RISCVCPUConfig {
     bool ext_zve32f;
     bool ext_zve64f;
     bool rvv_ta_all_1s;
+    bool rvv_ma_all_1s;
 
     /* Vendor-specific custom extensions */
     bool ext_XVentanaCondOps;
@@ -518,6 +519,7 @@ FIELD(TB_FLAGS, XL, 20, 2)
 FIELD(TB_FLAGS, PM_MASK_ENABLED, 22, 1)
 FIELD(TB_FLAGS, PM_BASE_ENABLED, 23, 1)
 FIELD(TB_FLAGS, VTA, 24, 1)
+FIELD(TB_FLAGS, VMA, 25, 1)
 
 #ifdef TARGET_RISCV32
 #define riscv_cpu_mxl(env)  ((void)(env), MXL_RV32)
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 2941c88c31..be94d82ff8 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -67,6 +67,8 @@ void cpu_get_tb_cpu_state(CPURISCVState *env, target_ulong *pc,
         flags = FIELD_DP32(flags, TB_FLAGS, VL_EQ_VLMAX, vl_eq_vlmax);
         flags = FIELD_DP32(flags, TB_FLAGS, VTA,
                     FIELD_EX64(env->vtype, VTYPE, VTA));
+        flags = FIELD_DP32(flags, TB_FLAGS, VMA,
+                    FIELD_EX64(env->vtype, VTYPE, VMA));
     } else {
         flags = FIELD_DP32(flags, TB_FLAGS, VILL, 1);
     }
diff --git a/target/riscv/insn_trans/trans_rvv.c.inc b/target/riscv/insn_trans/trans_rvv.c.inc
index 8d87501e03..4610107fb4 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -1251,6 +1251,7 @@ do_opivv_gvec(DisasContext *s, arg_rmrr *a, GVecGen3Fn *gvec_fn,
         data = FIELD_DP32(data, VDATA, VM, a->vm);
         data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
         data = FIELD_DP32(data, VDATA, VTA, s->vta);
+        data = FIELD_DP32(data, VDATA, VMA, s->vma);
         tcg_gen_gvec_4_ptr(vreg_ofs(s, a->rd), vreg_ofs(s, 0),
                            vreg_ofs(s, a->rs1), vreg_ofs(s, a->rs2),
                            cpu_env, s->cfg_ptr->vlen / 8,
@@ -1567,6 +1568,7 @@ static bool do_opivv_widen(DisasContext *s, arg_rmrr *a,
         data = FIELD_DP32(data, VDATA, VM, a->vm);
         data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
         data = FIELD_DP32(data, VDATA, VTA, s->vta);
+        data = FIELD_DP32(data, VDATA, VMA, s->vma);
         tcg_gen_gvec_4_ptr(vreg_ofs(s, a->rd), vreg_ofs(s, 0),
                            vreg_ofs(s, a->rs1),
                            vreg_ofs(s, a->rs2),
@@ -1649,6 +1651,7 @@ static bool do_opiwv_widen(DisasContext *s, arg_rmrr *a,
         data = FIELD_DP32(data, VDATA, VM, a->vm);
         data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
         data = FIELD_DP32(data, VDATA, VTA, s->vta);
+        data = FIELD_DP32(data, VDATA, VMA, s->vma);
         tcg_gen_gvec_4_ptr(vreg_ofs(s, a->rd), vreg_ofs(s, 0),
                            vreg_ofs(s, a->rs1),
                            vreg_ofs(s, a->rs2),
diff --git a/target/riscv/internals.h b/target/riscv/internals.h
index 512c6c30cf..00b72fd767 100644
--- a/target/riscv/internals.h
+++ b/target/riscv/internals.h
@@ -25,8 +25,9 @@
 FIELD(VDATA, VM, 0, 1)
 FIELD(VDATA, LMUL, 1, 3)
 FIELD(VDATA, VTA, 4, 1)
-FIELD(VDATA, NF, 5, 4)
-FIELD(VDATA, WD, 5, 1)
+FIELD(VDATA, VMA, 5, 1)
+FIELD(VDATA, NF, 6, 4)
+FIELD(VDATA, WD, 6, 1)
 
 /* float point classify helpers */
 target_ulong fclass_h(uint64_t frs1);
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 7775dade26..37893aa348 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -95,6 +95,7 @@ typedef struct DisasContext {
     int8_t lmul;
     uint8_t sew;
     uint8_t vta;
+    uint8_t vma;
     target_ulong vstart;
     bool vl_eq_vlmax;
     uint8_t ntemp;
@@ -1085,6 +1086,7 @@ static void riscv_tr_init_disas_context(DisasContextBase *dcbase, CPUState *cs)
     ctx->sew = FIELD_EX32(tb_flags, TB_FLAGS, SEW);
     ctx->lmul = sextract32(FIELD_EX32(tb_flags, TB_FLAGS, LMUL), 0, 3);
     ctx->vta = FIELD_EX32(tb_flags, TB_FLAGS, VTA) && cpu->cfg.rvv_ta_all_1s;
+    ctx->vma = FIELD_EX32(tb_flags, TB_FLAGS, VMA) && cpu->cfg.rvv_ma_all_1s;
     ctx->vstart = env->vstart;
     ctx->vl_eq_vlmax = FIELD_EX32(tb_flags, TB_FLAGS, VL_EQ_VLMAX);
     ctx->misa_mxl_max = env->misa_mxl_max;
diff --git a/target/riscv/vector_helper.c b/target/riscv/vector_helper.c
index fbde0c9248..141a06ddf0 100644
--- a/target/riscv/vector_helper.c
+++ b/target/riscv/vector_helper.c
@@ -127,6 +127,11 @@ static inline uint32_t vext_vta(uint32_t desc)
     return FIELD_EX32(simd_data(desc), VDATA, VTA);
 }
 
+static inline uint32_t vext_vma(uint32_t desc)
+{
+    return FIELD_EX32(simd_data(desc), VDATA, VMA);
+}
+
 /*
  * Get the maximum number of elements can be operated.
  *
@@ -797,10 +802,13 @@ static void do_vext_vv(void *vd, void *v0, void *vs1, void *vs2,
     uint32_t vl = env->vl;
     uint32_t total_elems = vext_get_total_elems(desc, esz);
     uint32_t vta = vext_vta(desc);
+    uint32_t vma = vext_vma(desc);
     uint32_t i;
 
     for (i = env->vstart; i < vl; i++) {
         if (!vm && !vext_elem_mask(v0, i)) {
+            /* set masked-off elements to 1s */
+            vext_set_elems_1s_fns[ctzl(esz)](vd, vma, i, i * esz, (i + 1) * esz);
             continue;
         }
         fn(vd, vs1, vs2, i);
-- 
2.34.2
Re: [PATCH qemu 1/9] target/riscv: rvv: Add mask agnostic for vv instructions
Posted by Weiwei Li 3 years, 9 months ago
在 2022/3/17 下午3:26, ~eopxd 写道:
> From: Yueh-Ting (eop) Chen <eop.chen@sifive.com>
>
> This is the first commit regarding the mask agnostic behavior.
> Added option 'rvv_ma_all_1s' to enable the behavior, the option
> is default to false.
>
> Signed-off-by: eop Chen <eop.chen@sifive.com>
> Reviewed-by: Frank Chang <frank.chang@sifive.com>
> ---
>   target/riscv/cpu.c                      | 1 +
>   target/riscv/cpu.h                      | 2 ++
>   target/riscv/cpu_helper.c               | 2 ++
>   target/riscv/insn_trans/trans_rvv.c.inc | 3 +++
>   target/riscv/internals.h                | 5 +++--
>   target/riscv/translate.c                | 2 ++
>   target/riscv/vector_helper.c            | 8 ++++++++
>   7 files changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index cd4cf4b41e..2bf862a5e4 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -811,6 +811,7 @@ static Property riscv_cpu_properties[] = {
>   
>       DEFINE_PROP_UINT64("resetvec", RISCVCPU, cfg.resetvec, DEFAULT_RSTVEC),
>       DEFINE_PROP_BOOL("rvv_ta_all_1s", RISCVCPU, cfg.rvv_ta_all_1s, false),
> +    DEFINE_PROP_BOOL("rvv_ma_all_1s", RISCVCPU, cfg.rvv_ma_all_1s, false),
>       DEFINE_PROP_END_OF_LIST(),
>   };
>   
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index 8c4a79b5a0..c76ded515b 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -370,6 +370,7 @@ struct RISCVCPUConfig {
>       bool ext_zve32f;
>       bool ext_zve64f;
>       bool rvv_ta_all_1s;
> +    bool rvv_ma_all_1s;
>   
>       /* Vendor-specific custom extensions */
>       bool ext_XVentanaCondOps;
> @@ -518,6 +519,7 @@ FIELD(TB_FLAGS, XL, 20, 2)
>   FIELD(TB_FLAGS, PM_MASK_ENABLED, 22, 1)
>   FIELD(TB_FLAGS, PM_BASE_ENABLED, 23, 1)
>   FIELD(TB_FLAGS, VTA, 24, 1)
> +FIELD(TB_FLAGS, VMA, 25, 1)
>   
>   #ifdef TARGET_RISCV32
>   #define riscv_cpu_mxl(env)  ((void)(env), MXL_RV32)
> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
> index 2941c88c31..be94d82ff8 100644
> --- a/target/riscv/cpu_helper.c
> +++ b/target/riscv/cpu_helper.c
> @@ -67,6 +67,8 @@ void cpu_get_tb_cpu_state(CPURISCVState *env, target_ulong *pc,
>           flags = FIELD_DP32(flags, TB_FLAGS, VL_EQ_VLMAX, vl_eq_vlmax);
>           flags = FIELD_DP32(flags, TB_FLAGS, VTA,
>                       FIELD_EX64(env->vtype, VTYPE, VTA));
> +        flags = FIELD_DP32(flags, TB_FLAGS, VMA,
> +                    FIELD_EX64(env->vtype, VTYPE, VMA));
>       } else {
>           flags = FIELD_DP32(flags, TB_FLAGS, VILL, 1);
>       }
> diff --git a/target/riscv/insn_trans/trans_rvv.c.inc b/target/riscv/insn_trans/trans_rvv.c.inc
> index 8d87501e03..4610107fb4 100644
> --- a/target/riscv/insn_trans/trans_rvv.c.inc
> +++ b/target/riscv/insn_trans/trans_rvv.c.inc
> @@ -1251,6 +1251,7 @@ do_opivv_gvec(DisasContext *s, arg_rmrr *a, GVecGen3Fn *gvec_fn,
>           data = FIELD_DP32(data, VDATA, VM, a->vm);
>           data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
>           data = FIELD_DP32(data, VDATA, VTA, s->vta);
> +        data = FIELD_DP32(data, VDATA, VMA, s->vma);
>           tcg_gen_gvec_4_ptr(vreg_ofs(s, a->rd), vreg_ofs(s, 0),
>                              vreg_ofs(s, a->rs1), vreg_ofs(s, a->rs2),
>                              cpu_env, s->cfg_ptr->vlen / 8,
> @@ -1567,6 +1568,7 @@ static bool do_opivv_widen(DisasContext *s, arg_rmrr *a,
>           data = FIELD_DP32(data, VDATA, VM, a->vm);
>           data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
>           data = FIELD_DP32(data, VDATA, VTA, s->vta);
> +        data = FIELD_DP32(data, VDATA, VMA, s->vma);
>           tcg_gen_gvec_4_ptr(vreg_ofs(s, a->rd), vreg_ofs(s, 0),
>                              vreg_ofs(s, a->rs1),
>                              vreg_ofs(s, a->rs2),
> @@ -1649,6 +1651,7 @@ static bool do_opiwv_widen(DisasContext *s, arg_rmrr *a,
>           data = FIELD_DP32(data, VDATA, VM, a->vm);
>           data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
>           data = FIELD_DP32(data, VDATA, VTA, s->vta);
> +        data = FIELD_DP32(data, VDATA, VMA, s->vma);
>           tcg_gen_gvec_4_ptr(vreg_ofs(s, a->rd), vreg_ofs(s, 0),
>                              vreg_ofs(s, a->rs1),
>                              vreg_ofs(s, a->rs2),
> diff --git a/target/riscv/internals.h b/target/riscv/internals.h
> index 512c6c30cf..00b72fd767 100644
> --- a/target/riscv/internals.h
> +++ b/target/riscv/internals.h
> @@ -25,8 +25,9 @@
>   FIELD(VDATA, VM, 0, 1)
>   FIELD(VDATA, LMUL, 1, 3)
>   FIELD(VDATA, VTA, 4, 1)
> -FIELD(VDATA, NF, 5, 4)
> -FIELD(VDATA, WD, 5, 1)
> +FIELD(VDATA, VMA, 5, 1)
> +FIELD(VDATA, NF, 6, 4)
> +FIELD(VDATA, WD, 6, 1)
>   
>   /* float point classify helpers */
>   target_ulong fclass_h(uint64_t frs1);
> diff --git a/target/riscv/translate.c b/target/riscv/translate.c
> index 7775dade26..37893aa348 100644
> --- a/target/riscv/translate.c
> +++ b/target/riscv/translate.c
> @@ -95,6 +95,7 @@ typedef struct DisasContext {
>       int8_t lmul;
>       uint8_t sew;
>       uint8_t vta;
> +    uint8_t vma;
>       target_ulong vstart;
>       bool vl_eq_vlmax;
>       uint8_t ntemp;
> @@ -1085,6 +1086,7 @@ static void riscv_tr_init_disas_context(DisasContextBase *dcbase, CPUState *cs)
>       ctx->sew = FIELD_EX32(tb_flags, TB_FLAGS, SEW);
>       ctx->lmul = sextract32(FIELD_EX32(tb_flags, TB_FLAGS, LMUL), 0, 3);
>       ctx->vta = FIELD_EX32(tb_flags, TB_FLAGS, VTA) && cpu->cfg.rvv_ta_all_1s;
> +    ctx->vma = FIELD_EX32(tb_flags, TB_FLAGS, VMA) && cpu->cfg.rvv_ma_all_1s;
>       ctx->vstart = env->vstart;
>       ctx->vl_eq_vlmax = FIELD_EX32(tb_flags, TB_FLAGS, VL_EQ_VLMAX);
>       ctx->misa_mxl_max = env->misa_mxl_max;
> diff --git a/target/riscv/vector_helper.c b/target/riscv/vector_helper.c
> index fbde0c9248..141a06ddf0 100644
> --- a/target/riscv/vector_helper.c
> +++ b/target/riscv/vector_helper.c
> @@ -127,6 +127,11 @@ static inline uint32_t vext_vta(uint32_t desc)
>       return FIELD_EX32(simd_data(desc), VDATA, VTA);
>   }
>   
> +static inline uint32_t vext_vma(uint32_t desc)
> +{
> +    return FIELD_EX32(simd_data(desc), VDATA, VMA);
> +}
> +
>   /*
>    * Get the maximum number of elements can be operated.
>    *
> @@ -797,10 +802,13 @@ static void do_vext_vv(void *vd, void *v0, void *vs1, void *vs2,
>       uint32_t vl = env->vl;
>       uint32_t total_elems = vext_get_total_elems(desc, esz);
>       uint32_t vta = vext_vta(desc);
> +    uint32_t vma = vext_vma(desc);
>       uint32_t i;
>   
>       for (i = env->vstart; i < vl; i++) {
>           if (!vm && !vext_elem_mask(v0, i)) {
> +            /* set masked-off elements to 1s */
> +            vext_set_elems_1s_fns[ctzl(esz)](vd, vma, i, i * esz, (i + 1) * esz);

Similar to our last discussion,  vext_set_elems_1s_fns array can be 
simplified to single vext_set_elems_1s,

since the fourth argement can be used as the start offset.

Another question, may be not related to this patchset, in section 3.4.3 
of the spec:

/"Mask destination tail elements are always treated as tail-agnostic, 
regardless of the setting of vta."/

What does "Mask destination tail elements" mean?

Regards,

Weiwei Li

>               continue;
>           }
>           fn(vd, vs1, vs2, i);
Re: [PATCH qemu 1/9] target/riscv: rvv: Add mask agnostic for vv instructions
Posted by eop Chen 3 years, 9 months ago
> Weiwei Li <liweiwei@iscas.ac.cn> 於 2022年4月26日 下午4:47 寫道:
> 在 2022/3/17 下午3:26, ~eopxd 写道:
>> From: Yueh-Ting (eop) Chen <eop.chen@sifive.com> <mailto:eop.chen@sifive.com>
>> 
>> This is the first commit regarding the mask agnostic behavior.
>> Added option 'rvv_ma_all_1s' to enable the behavior, the option
>> is default to false.
>> 
>> Signed-off-by: eop Chen <eop.chen@sifive.com> <mailto:eop.chen@sifive.com>
>> Reviewed-by: Frank Chang <frank.chang@sifive.com> <mailto:frank.chang@sifive.com>
> Similar to our last discussion,  vext_set_elems_1s_fns array can be simplified to single vext_set_elems_1s,
> 
> since the fourth argement can be used as the start offset. 
> 
> Another question, may be not related to this patchset, in section 3.4.3 of the spec: 
> 
> "Mask destination tail elements are always treated as tail-agnostic, regardless of the setting of vta."
> 
> What does "Mask destination tail elements" mean?
> 
> Regards,
> 
> Weiwei Li
> 


I have just updated a new version for the tail agnostic patch set, it also includes a bug fix discovered today.

Regarding the question, mask / masked-off are for body elements and respects the mask policy, and tail elements respect the tail policy.

Regards,

eop Chen
Re: [PATCH qemu 1/9] target/riscv: rvv: Add mask agnostic for vv instructions
Posted by Weiwei Li 3 years, 9 months ago
在 2022/4/27 上午2:20, eop Chen 写道:
>
>> Weiwei Li <liweiwei@iscas.ac.cn <mailto:liweiwei@iscas.ac.cn>> 於 
>> 2022年4月26日 下午4:47 寫道:
>> 在 2022/3/17 下午3:26, ~eopxd 写道:
>>> From: Yueh-Ting (eop) Chen<eop.chen@sifive.com>
>>>
>>> This is the first commit regarding the mask agnostic behavior.
>>> Added option 'rvv_ma_all_1s' to enable the behavior, the option
>>> is default to false.
>>>
>>> Signed-off-by: eop Chen<eop.chen@sifive.com>
>>> Reviewed-by: Frank Chang<frank.chang@sifive.com>
>>
>> Similar to our last discussion, vext_set_elems_1s_fns array can be 
>> simplified to single vext_set_elems_1s,
>>
>> since the fourth argement can be used as the start offset.
>>
>> Another question, may be not related to this patchset, in section 
>> 3.4.3 of the spec:
>>
>> /"Mask destination tail elements are always treated as tail-agnostic, 
>> regardless of the setting of vta."/
>>
>> What does "Mask destination tail elements" mean?
>>
>> Regards,
>>
>> Weiwei Li
>>
>
> I have just updated a new version for the tail agnostic patch set, it 
> also includes a bug fix discovered today.
>
> Regarding the question, mask / masked-off are for body elements and 
> respects the mask policy, and tail elements respect the tail policy.
>
> Regards,
>
> eop Chen

I find another descriptions in the spec. For the instructions that write 
mask register (such as vmadc, vmseq,vmsne,vmfeq...), they all have 
similar description

(You can search "tail-agnostic" in the spec):

/Section 11.4: "Because these instructions produce a mask value, they 
always operate with a tail-agnostic policy"//
/

/Section 11.8/13.13: "Compares //write mask registers, and so always 
operate under a tail-agnostic policy"//
/

/Section 15.1: "Mask elements past vl, the tail elements, are always 
updated with a tail-agnostic policy"//
/

//

/Section 15.4/15.5/15.6: "The tail elements in the destination mask 
register are updated under a tail-agnostic policy"/

So I think "Mask destination tail elements" may means the tail element 
for instructions that take mask register as destination register.  For 
these instructions,

maybe the setting of VTA can be ignored.

Regards,

Weiwei Li

Re: [PATCH qemu 1/9] target/riscv: rvv: Add mask agnostic for vv instructions
Posted by eop Chen 3 years, 9 months ago

> 
> 在 2022/4/27 上午2:20, eop Chen 写道:
>> 
>>> Weiwei Li <liweiwei@iscas.ac.cn <mailto:liweiwei@iscas.ac.cn>> 於 2022年4月26日 下午4:47 寫道:
>>> 在 2022/3/17 下午3:26, ~eopxd 写道:
>>>> From: Yueh-Ting (eop) Chen <eop.chen@sifive.com> <mailto:eop.chen@sifive.com>
>>>> 
>>>> This is the first commit regarding the mask agnostic behavior.
>>>> Added option 'rvv_ma_all_1s' to enable the behavior, the option
>>>> is default to false.
>>>> 
>>>> Signed-off-by: eop Chen <eop.chen@sifive.com> <mailto:eop.chen@sifive.com>
>>>> Reviewed-by: Frank Chang <frank.chang@sifive.com> <mailto:frank.chang@sifive.com>
>>> Similar to our last discussion,  vext_set_elems_1s_fns array can be simplified to single vext_set_elems_1s,
>>> 
>>> since the fourth argement can be used as the start offset. 
>>> 
>>> Another question, may be not related to this patchset, in section 3.4.3 of the spec: 
>>> 
>>> "Mask destination tail elements are always treated as tail-agnostic, regardless of the setting of vta."
>>> 
>>> What does "Mask destination tail elements" mean?
>>> 
>>> Regards,
>>> 
>>> Weiwei Li
>>> 
>> 
>> 
>> I have just updated a new version for the tail agnostic patch set, it also includes a bug fix discovered today.
>> 
>> Regarding the question, mask / masked-off are for body elements and respects the mask policy, and tail elements respect the tail policy.
>> 
>> Regards,
>> 
>> eop Chen
> 
> I find another descriptions in the spec. For the instructions that write mask register (such as vmadc, vmseq,vmsne,vmfeq...), they all have similar description
> 
> (You can search "tail-agnostic" in the spec):
> 
> Section 11.4: "Because these instructions produce a mask value, they always operate with a tail-agnostic policy"
> 
> Section 11.8/13.13: "Compares write mask registers, and so always operate under a tail-agnostic policy"
> 
> Section 15.1: "Mask elements past vl, the tail elements, are always updated with a tail-agnostic policy"
> 
> Section 15.4/15.5/15.6: "The tail elements in the destination mask register are updated under a tail-agnostic policy"
> 
> So I think "Mask destination tail elements" may means the tail element for instructions that take mask register as destination register.  For these instructions, 
> 
> maybe the setting of VTA can be ignored.  
> 
> Regards,
> 
> Weiwei Li
> 

Yes, the setting of VTA should be ignored when v-spec specifies.
I think the implementation of the tail agnostic patch set don’t need to change on this.

Regards,

eop Chen



Re: [PATCH qemu 1/9] target/riscv: rvv: Add mask agnostic for vv instructions
Posted by Weiwei Li 3 years, 9 months ago
在 2022/4/27 上午10:07, eop Chen 写道:
>
>
>>
>> 在 2022/4/27 上午2:20, eop Chen 写道:
>>>
>>>> Weiwei Li <liweiwei@iscas.ac.cn <mailto:liweiwei@iscas.ac.cn>> 於 
>>>> 2022年4月26日 下午4:47 寫道:
>>>> 在 2022/3/17 下午3:26, ~eopxd 写道:
>>>>> From: Yueh-Ting (eop) Chen<eop.chen@sifive.com>
>>>>>
>>>>> This is the first commit regarding the mask agnostic behavior.
>>>>> Added option 'rvv_ma_all_1s' to enable the behavior, the option
>>>>> is default to false.
>>>>>
>>>>> Signed-off-by: eop Chen<eop.chen@sifive.com>
>>>>> Reviewed-by: Frank Chang<frank.chang@sifive.com>
>>>>
>>>> Similar to our last discussion, vext_set_elems_1s_fns array can be 
>>>> simplified to single vext_set_elems_1s,
>>>>
>>>> since the fourth argement can be used as the start offset.
>>>>
>>>> Another question, may be not related to this patchset, in section 
>>>> 3.4.3 of the spec:
>>>>
>>>> /"Mask destination tail elements are always treated as 
>>>> tail-agnostic, regardless of the setting of vta."/
>>>>
>>>> What does "Mask destination tail elements" mean?
>>>>
>>>> Regards,
>>>>
>>>> Weiwei Li
>>>>
>>>
>>> I have just updated a new version for the tail agnostic patch set, 
>>> it also includes a bug fix discovered today.
>>>
>>> Regarding the question, mask / masked-off are for body elements and 
>>> respects the mask policy, and tail elements respect the tail policy.
>>>
>>> Regards,
>>>
>>> eop Chen
>>
>> I find another descriptions in the spec. For the instructions that 
>> write mask register (such as vmadc, vmseq,vmsne,vmfeq...), they all 
>> have similar description
>>
>> (You can search "tail-agnostic" in the spec):
>>
>> /Section 11.4: "Because these instructions produce a mask value, they 
>> always operate with a tail-agnostic policy"//
>> /
>>
>> /Section 11.8/13.13: "Compares //write mask registers, and so always 
>> operate under a tail-agnostic policy"//
>> /
>>
>> /Section 15.1: "Mask elements past vl, the tail elements, are always 
>> updated with a tail-agnostic policy"//
>> /
>>
>> //
>>
>> /Section 15.4/15.5/15.6: "The tail elements in the destination mask 
>> register are updated under a tail-agnostic policy"/
>>
>> So I think "Mask destination tail elements" may means the tail 
>> element for instructions that take mask register as destination 
>> register.  For these instructions,
>>
>> maybe the setting of VTA can be ignored.
>>
>> Regards,
>>
>> Weiwei Li
>>
>
> Yes, the setting of VTA should be ignored when v-spec specifies.
> I think the implementation of the tail agnostic patch set don’t need 
> to change on this.

Sorry. I don't get your idea?

In current patch, these instructions seems need to set the tail elements 
to 1s when vta is true which means

VTA is setted and rvv_ta_all_1s is enabled. If setting of VTA should be 
ignored for these instrucitons,

they will set the tail elements to 1s only when rvv_ta_all_1s is enabled.

Regards,

Weiwei Li

>
> Regards,
>
> eop Chen
>
>
>
Re: [PATCH qemu 1/9] target/riscv: rvv: Add mask agnostic for vv instructions
Posted by eop Chen 3 years, 9 months ago

> Weiwei Li <liweiwei@iscas.ac.cn> 於 2022年4月27日 上午11:27 寫道:
> 
> 
> 
> 在 2022/4/27 上午10:07, eop Chen 写道:
>> 
>> 
>>> 
>>> 在 2022/4/27 上午2:20, eop Chen 写道:
>>>> 
>>>>> Weiwei Li <liweiwei@iscas.ac.cn <mailto:liweiwei@iscas.ac.cn>> 於 2022年4月26日 下午4:47 寫道:
>>>>> 在 2022/3/17 下午3:26, ~eopxd 写道:
>>>>>> From: Yueh-Ting (eop) Chen <eop.chen@sifive.com> <mailto:eop.chen@sifive.com>
>>>>>> 
>>>>>> This is the first commit regarding the mask agnostic behavior.
>>>>>> Added option 'rvv_ma_all_1s' to enable the behavior, the option
>>>>>> is default to false.
>>>>>> 
>>>>>> Signed-off-by: eop Chen <eop.chen@sifive.com> <mailto:eop.chen@sifive.com>
>>>>>> Reviewed-by: Frank Chang <frank.chang@sifive.com> <mailto:frank.chang@sifive.com>
>>>>> Similar to our last discussion,  vext_set_elems_1s_fns array can be simplified to single vext_set_elems_1s,
>>>>> 
>>>>> since the fourth argement can be used as the start offset. 
>>>>> 
>>>>> Another question, may be not related to this patchset, in section 3.4.3 of the spec: 
>>>>> 
>>>>> "Mask destination tail elements are always treated as tail-agnostic, regardless of the setting of vta."
>>>>> 
>>>>> What does "Mask destination tail elements" mean?
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Weiwei Li
>>>>> 
>>>> 
>>>> 
>>>> I have just updated a new version for the tail agnostic patch set, it also includes a bug fix discovered today.
>>>> 
>>>> Regarding the question, mask / masked-off are for body elements and respects the mask policy, and tail elements respect the tail policy.
>>>> 
>>>> Regards,
>>>> 
>>>> eop Chen
>>> 
>>> I find another descriptions in the spec. For the instructions that write mask register (such as vmadc, vmseq,vmsne,vmfeq...), they all have similar description
>>> 
>>> (You can search "tail-agnostic" in the spec):
>>> 
>>> Section 11.4: "Because these instructions produce a mask value, they always operate with a tail-agnostic policy"
>>> 
>>> Section 11.8/13.13: "Compares write mask registers, and so always operate under a tail-agnostic policy"
>>> 
>>> Section 15.1: "Mask elements past vl, the tail elements, are always updated with a tail-agnostic policy"
>>> 
>>> Section 15.4/15.5/15.6: "The tail elements in the destination mask register are updated under a tail-agnostic policy"
>>> 
>>> So I think "Mask destination tail elements" may means the tail element for instructions that take mask register as destination register.  For these instructions, 
>>> 
>>> maybe the setting of VTA can be ignored.  
>>> 
>>> Regards,
>>> 
>>> Weiwei Li
>>> 
>> 
>> Yes, the setting of VTA should be ignored when v-spec specifies.
>> I think the implementation of the tail agnostic patch set don’t need to change on this.
> Sorry. I don't get your idea? 
> 
> In current patch, these instructions seems need to set the tail elements to 1s when vta is true which means
> 
> VTA is setted and rvv_ta_all_1s is enabled. If setting of VTA should be ignored for these instrucitons,  
> 
> they will set the tail elements to 1s only when rvv_ta_all_1s is enabled.
> 
> Regards,
> 
> Weiwei Li
> 
>> 
>> Regards,
>> 
>> eop Chen
>> 
>> 
>> 

I see your point now. Yes the implementation should be changed.
Let me submit a new version for this.

Regards,

eop Chen