public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Christoph Müllner" <christoph.muellner@vrull.eu>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: gcc-patches@gcc.gnu.org, Kito Cheng <kito.cheng@sifive.com>,
	 Jim Wilson <jim.wilson.gcc@gmail.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	 Andrew Waterman <andrew@sifive.com>,
	Philipp Tomsich <philipp.tomsich@vrull.eu>,
	 Cooper Qu <cooper.qu@linux.alibaba.com>,
	Lifang Xia <lifang_xia@linux.alibaba.com>,
	 Yunhai Shang <yunhai@linux.alibaba.com>,
	Zhiwei Liu <zhiwei_liu@linux.alibaba.com>
Subject: Re: [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx ISA extension
Date: Wed, 28 Jun 2023 14:39:25 +0200	[thread overview]
Message-ID: <CAEg0e7he7n2-SssMR3r2-BuKznQjj1bVgG5PsUOsX3oG84nZgQ@mail.gmail.com> (raw)
In-Reply-To: <a76e7cb1-4f6c-f15f-468a-0a804bbf2458@gmail.com>

On Sat, Jun 10, 2023 at 7:53 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
> On 4/28/23 00:23, Christoph Muellner wrote:
> > From: Christoph Müllner <christoph.muellner@vrull.eu>
> >
> > The XTheadMemIdx ISA extension provides a additional load and store
> > instructions with new addressing modes.
> >
> > The following memory accesses types are supported:
> > * ltype = [b,bu,h,hu,w,wu,d]
> > * stype = [b,h,w,d]
> >
> > The following addressing modes are supported:
> > * immediate offset with PRE_MODIFY or POST_MODIFY (22 instructions):
> >    l<ltype>.ia, l<ltype>.ib, s<stype>.ia, s<stype>.ib
> > * register offset with additional immediate offset (11 instructions):
> >    lr<ltype>, sr<stype>
> > * zero-extended register offset with additional immediate offset
> >    (11 instructions): lur<ltype>, sur<stype>
> >
> > The RISC-V base ISA does not support index registers, so the changes
> > are kept separate from the RISC-V standard support.
> >
> > Similar like other extensions (Zbb, XTheadBb), this patch needs to
> > prevent the conversion of sign-extensions/zero-extensions into
> > shift instructions. The case of the zero-extended register offset
> > addressing mode is handled by a new peephole pass.
> >
> > Handling the different cases of extensions results in a couple of INSNs
> > that look redundant on first view, but they are just the equivalent
> > of what we already have for Zbb as well. The only difference is, that
> > we have much more load instructions.
> >
> > To fully utilize the capabilities of the instructions, there are
> > a few new peephole passes which fold shift amounts into the RTX
> > if possible. The added tests ensure that this feature won't
> > regress without notice.
> >
> > We already have a constraint with the name 'th_f_fmv', therefore,
> > the new constraints follow this pattern and have the same length
> > as required ('th_m_mia', 'th_m_mib', 'th_m_mir', 'th_m_miu').
> >
> > gcc/ChangeLog:
> >
> >       * config/riscv/constraints.md (th_m_mia): New constraint.
> >       (th_m_mib): Likewise.
> >       (th_m_mir): Likewise.
> >       (th_m_miu): Likewise.
> >       * config/riscv/riscv-protos.h (enum riscv_address_type):
> >       Add new address types ADDRESS_REG_REG, ADDRESS_REG_UREG,
> >       and ADDRESS_REG_WB and their documentation.
> >       (struct riscv_address_info): Add new field 'shift' and
> >       document the field usage for the new address types.
> >       (riscv_valid_base_register_p): New prototype.
> >       (th_memidx_legitimate_modify_p): Likewise.
> >       (th_memidx_legitimate_index_p): Likewise.
> >       (th_classify_address): Likewise.
> >       (th_output_move): Likewise.
> >       (th_print_operand_address): Likewise.
> >       * config/riscv/riscv.cc (riscv_index_reg_class):
> >       Return GR_REGS for XTheadMemIdx.
> >       (riscv_regno_ok_for_index_p): Add support for XTheadMemIdx.
> >       (riscv_classify_address): Call th_classify_address() on top.
> >       (riscv_output_move): Call th_output_move() on top.
> >       (riscv_print_operand_address): Call th_print_operand_address()
> >       on top.
> >       * config/riscv/riscv.h (HAVE_POST_MODIFY_DISP): New macro.
> >       (HAVE_PRE_MODIFY_DISP): Likewise.
> >       * config/riscv/riscv.md (zero_extendqi<SUPERQI:mode>2): Disable
> >       for XTheadMemIdx.
> >       (*zero_extendqi<SUPERQI:mode>2_internal): Convert to expand,
> >       create INSN with same name and disable it for XTheadMemIdx.
> >       (extendsidi2): Likewise.
> >       (*extendsidi2_internal): Disable for XTheadMemIdx.
> >       * config/riscv/thead-peephole.md: Add helper peephole passes.
> >       * config/riscv/thead.cc (valid_signed_immediate): New helper
> >       function.
> >       (th_memidx_classify_address_modify): New function.
> >       (th_memidx_legitimate_modify_p): Likewise.
> >       (th_memidx_output_modify): Likewise.
> >       (is_memidx_mode): Likewise.
> >       (th_memidx_classify_address_index): Likewise.
> >       (th_memidx_legitimate_index_p): Likewise.
> >       (th_memidx_output_index): Likewise.
> >       (th_classify_address): Likewise.
> >       (th_output_move): Likewise.
> >       (th_print_operand_address): Likewise.
> >       * config/riscv/thead.md (*th_memidx_mov<mode>2):
> >       New INSN.
> >       (*th_memidx_zero_extendqi<SUPERQI:mode>2): Likewise.
> >       (*th_memidx_extendsidi2): Likewise
> >       (*th_memidx_zero_extendsidi2): Likewise.
> >       (*th_memidx_zero_extendhi<GPR:mode>2): Likewise.
> >       (*th_memidx_extend<SHORT:mode><SUPERQI:mode>2): Likewise
> >       (*th_memidx_bb_zero_extendsidi2): Likewise.
> >       (*th_memidx_bb_zero_extendhi<GPR:mode>2): Likewise.
> >       (*th_memidx_bb_extendhi<GPR:mode>2): Likewise.
> >       (*th_memidx_bb_extendqi<SUPERQI:mode>2): Likewise.
> >
> > gcc/testsuite/ChangeLog:
> >
> >       * gcc.target/riscv/xtheadmemidx-helpers.h: New test.
> >       * gcc.target/riscv/xtheadmemidx-index-update.c: New test.
> >       * gcc.target/riscv/xtheadmemidx-index-xtheadbb-update.c: New test.
> >       * gcc.target/riscv/xtheadmemidx-index-xtheadbb.c: New test.
> >       * gcc.target/riscv/xtheadmemidx-index.c: New test.
> >       * gcc.target/riscv/xtheadmemidx-modify-xtheadbb.c: New test.
> >       * gcc.target/riscv/xtheadmemidx-modify.c: New test.
> >       * gcc.target/riscv/xtheadmemidx-uindex-update.c: New test.
> >       * gcc.target/riscv/xtheadmemidx-uindex-xtheadbb-update.c: New test.
> >       * gcc.target/riscv/xtheadmemidx-uindex-xtheadbb.c: New test.
> >       * gcc.target/riscv/xtheadmemidx-uindex.c: New test.
> >
>
>
>
> > diff --git a/gcc/config/riscv/thead-peephole.md b/gcc/config/riscv/thead-peephole.md
> > index 5b829b5b968..2a4c734a220 100644
> > --- a/gcc/config/riscv/thead-peephole.md
> > +++ b/gcc/config/riscv/thead-peephole.md
> > @@ -72,3 +72,217 @@ (define_peephole2
> >   {
> >     th_mempair_order_operands (operands, true, SImode);
> >   })
> > +
> > +;; All modes that are supported by XTheadMemIdx
> > +(define_mode_iterator TH_M_ANY [QI HI SI (DI "TARGET_64BIT")])
> > +
> > +;; All non-extension modes that are supported by XTheadMemIdx
> > +(define_mode_iterator TH_M_NOEXT [(SI "!TARGET_64BIT") (DI "TARGET_64BIT")])
> > +
> > +;; XTheadMemIdx overview:
> > +;; All peephole passes attempt to improve the operand utilization of
> > +;; XTheadMemIdx instructions, where one sign or zero extended
> > +;; register-index-operand can be shifted left by a 2-bit immediate.
> > +;;
> > +;; The basic idea is the following optimization:
> > +;; (set (reg 0) (op (reg 1) (imm 2)))
> > +;; (set (reg 3) (mem (plus (reg 0) (reg 4)))
> > +;; ==>
> > +;; (set (reg 3) (mem (plus (reg 4) (op2 (reg 1) (imm 2))))
> > +;; This optimization only valid if (reg 0) has no further uses.
> Couldn't this be done by combine if you created define_insn patterns
> rather than define_peephole2 patterns?  Similarly for the other cases
> handled here.

I was inspired by XTheadMemPair, which merges two memory accesses
into a mem-pair instruction (and which got inspiration from
gcc/config/aarch64/aarch64-ldpstp.md).

I don't see the benefit of using combine or peephole, but I can change
if necessary. At least for the provided test cases, the implementation
works quite well.

>
> Do you need to define HAVE_{PRE,POST}_MODIFY?  I see
> HAVE_{PRE,POST}_MODIFY_DISP. is defined.  If that's sufficient, great.
> This stuff seems to have changed since I last looked at it.

There is no HAVE_{PRE,POST}_MODIFY, only HAVE_{PRE,POST}_MODIFY_REG (register)
and HAVE_{PRE,POST}_MODIFY_DISP (constant displacement).
The defined macros are matching the expectation of gcc/auto-inc-dec.cc
and also match the documentation.


> So I have to ask.  Is the extension documented?  If so, we probably
> should have a link to it.  What's the status of hardware availablity
> with this extension?

The basic support for this extension is already merged.

The documentation can be found here:
  https://github.com/T-head-Semi/thead-extension-spec/tree/master

The extension's name and a link to the documentation has also been
registered here:
  https://github.com/riscv-non-isa/riscv-toolchain-conventions#list-of-vendor-extensions

The XTheadMemIdx extension is part of the T-Head C906 and C910 SoCs.
The C906 was launched in October 2021.

Thanks
Christoph

  reply	other threads:[~2023-06-28 12:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-28  6:23 Christoph Muellner
2023-04-28  6:23 ` [PATCH 11/11] riscv: thead: Add support for the XTheadFMemIdx " Christoph Muellner
2023-06-10 17:54   ` Jeff Law
2023-06-28 12:39     ` Christoph Müllner
2023-06-10 17:53 ` [PATCH 10/11] riscv: thead: Add support for the XTheadMemIdx " Jeff Law
2023-06-28 12:39   ` Christoph Müllner [this message]
2023-06-28 18:23     ` Jeff Law
2023-06-29  7:39       ` Christoph Müllner
2023-06-29 14:09         ` Jeff Law
2023-07-06  6:48           ` Christoph Müllner
2023-07-06 15:28             ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEg0e7he7n2-SssMR3r2-BuKznQjj1bVgG5PsUOsX3oG84nZgQ@mail.gmail.com \
    --to=christoph.muellner@vrull.eu \
    --cc=andrew@sifive.com \
    --cc=cooper.qu@linux.alibaba.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=jim.wilson.gcc@gmail.com \
    --cc=kito.cheng@sifive.com \
    --cc=lifang_xia@linux.alibaba.com \
    --cc=palmer@dabbelt.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=yunhai@linux.alibaba.com \
    --cc=zhiwei_liu@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).