mbox series

[00/17] target/riscv: Use tcg_constant_*

Message ID 20210709042608.883256-1-richard.henderson@linaro.org
Headers show
Series target/riscv: Use tcg_constant_* | expand

Message

Richard Henderson July 9, 2021, 4:25 a.m. UTC
Replace use of tcg_const_*, which makes a copy into a temp
which must be freed, with direct use of the constant.

Reorg handling of $zero, with different accessors for
source and destination.

Reorg handling of csrs, passing the actual write_mask
instead of a regno.

Use more helpers for RVH expansion.


r~


Richard Henderson (17):
  target/riscv: Use tcg_constant_*
  target/riscv: Introduce gpr_src, gpr_dst
  target/riscv: Use gpr_{src,dst} in shift operations
  target/riscv: Use gpr_{src,dst} in word division operations
  target/riscv: Use gpr_{src,dst} and tcg_constant_tl in gen_grevi
  target/riscv: Use gpr_src in branches
  target/riscv: Use gpr_{src,dst} for integer load/store
  target/riscv: Use gpr_{src,dst} for word shift operations
  target/riscv: Reorg csr instructions
  target/riscv: Use gpr_{src,dst} for RVA
  target/riscv: Use gpr_{src,dst} for RVB
  target/riscv: Use gpr_{src,dst} for RVF
  target/riscv: Use gpr_{src,dst} for RVD
  target/riscv: Tidy trans_rvh.c.inc
  target/riscv: Use gen_arith for mulh and mulhu
  target/riscv: Use gpr_{src,dst} for RVV
  target/riscv: Remove gen_get_gpr

 target/riscv/helper.h                   |   6 +-
 target/riscv/insn32.decode              |   1 +
 target/riscv/op_helper.c                |  18 +-
 target/riscv/translate.c                | 273 +++++++++-----------
 target/riscv/insn_trans/trans_rva.c.inc |  42 ++--
 target/riscv/insn_trans/trans_rvb.c.inc |  11 +-
 target/riscv/insn_trans/trans_rvd.c.inc | 116 ++++-----
 target/riscv/insn_trans/trans_rvf.c.inc | 134 ++++------
 target/riscv/insn_trans/trans_rvh.c.inc | 264 ++++---------------
 target/riscv/insn_trans/trans_rvi.c.inc | 322 ++++++++++++++----------
 target/riscv/insn_trans/trans_rvm.c.inc |  24 +-
 target/riscv/insn_trans/trans_rvv.c.inc | 144 ++++-------
 12 files changed, 534 insertions(+), 821 deletions(-)

-- 
2.25.1

Comments

LIU Zhiwei July 15, 2021, 11:21 a.m. UTC | #1
On 2021/7/9 下午12:25, Richard Henderson wrote:
> Replace use of tcg_const_*, which makes a copy into a temp

> which must be freed, with direct use of the constant.

>

> Reorg handling of $zero, with different accessors for

> source and destination.

>

> Reorg handling of csrs, passing the actual write_mask

> instead of a regno.

>

> Use more helpers for RVH expansion.


Hi Richard,

In patch 09-17  target/riscv: Reorg csr instruction,  I think the 
parameter name 'rc'  can be renamed to 'csrno'.

Otherwise,
Reviewed-by: LIU Zhiwei <zhiwei_liu@c-sky.com>


Also on a side note, could you give me some advice for the following 
question?

I have been supporting  running 32bit application on qemu-riscv64. After 
this patch set,
it is hard to define a  method,  such as gpr_dst_s or gpr_dst_u, to 
extend the destination
register. I can only extend the destination register(ext32s or ext32u) 
in each instruction
with scattered code.

Can we just omit the extension of the destination register?

Best Regards,
Zhiwei



>

> r~

>

>

> Richard Henderson (17):

>    target/riscv: Use tcg_constant_*

>    target/riscv: Introduce gpr_src, gpr_dst

>    target/riscv: Use gpr_{src,dst} in shift operations

>    target/riscv: Use gpr_{src,dst} in word division operations

>    target/riscv: Use gpr_{src,dst} and tcg_constant_tl in gen_grevi

>    target/riscv: Use gpr_src in branches

>    target/riscv: Use gpr_{src,dst} for integer load/store

>    target/riscv: Use gpr_{src,dst} for word shift operations

>    target/riscv: Reorg csr instructions

>    target/riscv: Use gpr_{src,dst} for RVA

>    target/riscv: Use gpr_{src,dst} for RVB

>    target/riscv: Use gpr_{src,dst} for RVF

>    target/riscv: Use gpr_{src,dst} for RVD

>    target/riscv: Tidy trans_rvh.c.inc

>    target/riscv: Use gen_arith for mulh and mulhu

>    target/riscv: Use gpr_{src,dst} for RVV

>    target/riscv: Remove gen_get_gpr

>

>   target/riscv/helper.h                   |   6 +-

>   target/riscv/insn32.decode              |   1 +

>   target/riscv/op_helper.c                |  18 +-

>   target/riscv/translate.c                | 273 +++++++++-----------

>   target/riscv/insn_trans/trans_rva.c.inc |  42 ++--

>   target/riscv/insn_trans/trans_rvb.c.inc |  11 +-

>   target/riscv/insn_trans/trans_rvd.c.inc | 116 ++++-----

>   target/riscv/insn_trans/trans_rvf.c.inc | 134 ++++------

>   target/riscv/insn_trans/trans_rvh.c.inc | 264 ++++---------------

>   target/riscv/insn_trans/trans_rvi.c.inc | 322 ++++++++++++++----------

>   target/riscv/insn_trans/trans_rvm.c.inc |  24 +-

>   target/riscv/insn_trans/trans_rvv.c.inc | 144 ++++-------

>   12 files changed, 534 insertions(+), 821 deletions(-)

>
Richard Henderson July 15, 2021, 4:15 p.m. UTC | #2
On 7/15/21 4:21 AM, LIU Zhiwei wrote:
> Also on a side note, could you give me some advice for the following question?

> 

> I have been supporting  running 32bit application on qemu-riscv64. After this patch set,

> it is hard to define a  method,  such as gpr_dst_s or gpr_dst_u, to extend the destination

> register. I can only extend the destination register(ext32s or ext32u) in each instruction

> with scattered code.

> 

> Can we just omit the extension of the destination register?


It's hard to give advice on code that I haven't seen.

In general I would think that the destination register need not be extended for 32-bit 
mode, unless the architecture says otherwise.  (What does the architecture say about the 
contents of the registers when transitioning from a 32-bit mode user program to a 64-bit 
mode kernel?)


r~
LIU Zhiwei July 17, 2021, 3:59 a.m. UTC | #3
On 2021/7/16 上午12:15, Richard Henderson wrote:
> On 7/15/21 4:21 AM, LIU Zhiwei wrote:

>> Also on a side note, could you give me some advice for the following 

>> question?

>>

>> I have been supporting  running 32bit application on qemu-riscv64. 

>> After this patch set,

>> it is hard to define a  method,  such as gpr_dst_s or gpr_dst_u, to 

>> extend the destination

>> register. I can only extend the destination register(ext32s or 

>> ext32u) in each instruction

>> with scattered code.

>>

>> Can we just omit the extension of the destination register?

>

> It's hard to give advice on code that I haven't seen.

>

> In general I would think that the destination register need not be 

> extended for 32-bit mode, unless the architecture says otherwise. 

> (What does the architecture say about the contents of the registers 

> when transitioning from a 32-bit mode user program to a 64-bit mode 

> kernel?)

>

As privileged specification says,

"Whenever XLEN in any mode is set to a value less than the widest supported XLEN, all operations
must ignore source operand register bits above the configured XLEN, and must sign-extend results
to fill the entire widest supported XLEN in the destination register. Similarly, pc bits above XLEN
are ignored, and when the pc is written, it is sign-extended to fill the widest supported XLEN."

If we want to strictly obey the spec, we should
1) Ignore MSB 32bits for source register, and sign-extend the 
destination register.
2) Always use 32bit operation(TCG 32bit OP).

I want to still use TCG 64bit OP and just extend the source to 64bit by 
ext32s or ext32u.

Is is OK?

Thanks,
Zhiwei
>

> r~
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2021/7/16 上午12:15, Richard Henderson
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:0b70aaf7-b337-3b73-cdbf-c5693a826204@linaro.org">On
      7/15/21 4:21 AM, LIU Zhiwei wrote:
      <br>
      <blockquote type="cite">Also on a side note, could you give me
        some advice for the following question?
        <br>
        <br>
        I have been supporting  running 32bit application on
        qemu-riscv64. After this patch set,
        <br>
        it is hard to define a  method,  such as gpr_dst_s or gpr_dst_u,
        to extend the destination
        <br>
        register. I can only extend the destination register(ext32s or
        ext32u) in each instruction
        <br>
        with scattered code.
        <br>
        <br>
        Can we just omit the extension of the destination register?
        <br>
      </blockquote>
      <br>
      It's hard to give advice on code that I haven't seen.
      <br>
      <br>
      In general I would think that the destination register need not be
      extended for 32-bit mode, unless the architecture says otherwise. 
      (What does the architecture say about the contents of the
      registers when transitioning from a 32-bit mode user program to a
      64-bit mode kernel?)
      <br>
      <br>
    </blockquote>
    <p>As privileged specification says,</p>
    <pre>"Whenever XLEN in any mode is set to a value less than the widest supported XLEN, all operations
must ignore source operand register bits above the configured XLEN, and must sign-extend results
to fill the entire widest supported XLEN in the destination register. Similarly, pc bits above XLEN
are ignored, and when the pc is written, it is sign-extended to fill the widest supported XLEN."
</pre>
    If we want to strictly obey the spec, we should <br>
    1) Ignore MSB 32bits for source register, and sign-extend the
    destination register.<br>
    2) Always use 32bit operation(TCG 32bit OP).<br>
    <br>
    I want to still use TCG 64bit OP and just extend the source to 64bit
    by ext32s or ext32u.<br>
    <br>
    Is is OK?<br>
    <br>
    Thanks,<br>
    Zhiwei<br>
    <blockquote type="cite"
      cite="mid:0b70aaf7-b337-3b73-cdbf-c5693a826204@linaro.org">
      <br>
      r~
      <br>
    </blockquote>
  </body>
</html>
Richard Henderson July 17, 2021, 3:41 p.m. UTC | #4
On 7/16/21 8:59 PM, LIU Zhiwei wrote:
> If we want to strictly obey the spec, we should

> 1) Ignore MSB 32bits for source register, and sign-extend the destination register.

> 2) Always use 32bit operation(TCG 32bit OP).

> 

> I want to still use TCG 64bit OP and just extend the source to 64bit by ext32s or ext32u.

> 

> Is is OK?


Yes, that sounds right.


r~