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: Thu, 29 Jun 2023 09:39:28 +0200 [thread overview]
Message-ID: <CAEg0e7gA8kPs-YPG==oVtaj8buHsGF3jYOt4mr82Uy95oODWrA@mail.gmail.com> (raw)
In-Reply-To: <0e13e932-64c4-fe33-e0f8-21380809a6ba@gmail.com>
On Wed, Jun 28, 2023 at 8:23 PM Jeff Law <jeffreyalaw@gmail.com> wrote:
>
>
>
> On 6/28/23 06:39, Christoph Müllner wrote:
>
> >>> +;; 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).
> Right. I'm pretty familiar with those. They cover a different case,
> specifically the two insns being optimized don't have a true data
> dependency between them. ie, the first instruction does not produce a
> result used in the second insn.
>
>
> In the case above there is a data dependency on reg0. ie, the first
> instruction generates a result used in the second instruction. combine
> is usually the best place to handle the data dependency case.
Ok, understood.
It is a bit of a special case here, because the peephole is restricted
to those cases, where reg0 is not used elsewhere (peep2_reg_dead_p()).
I have not seen how to do this for combiner optimizations.
I found sh_remove_reg_dead_or_unused_notes(), which tests for reg notes
on a given rtx_insn. In our case we have a pattern that matches two insns,
where we have to test if one operand (reg0) is dead or unused after the second
insn. The first insn can be accessed with "curr_insn", but I did not see how to
access the second matching insn. Any ideas or hints?
Thanks,
Christoph
>
>
> >
> > 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.
> Peepholes require the instructions to be consecutive in the stream while
> combine relies on data dependence links and can thus find these
> opportunities even when the two insn we care about are separated by
> unrelated other insns.
>
>
> Jeff
next prev parent reply other threads:[~2023-06-29 7: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
2023-06-28 18:23 ` Jeff Law
2023-06-29 7:39 ` Christoph Müllner [this message]
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='CAEg0e7gA8kPs-YPG==oVtaj8buHsGF3jYOt4mr82Uy95oODWrA@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).