public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/108248] Some insns in the risc-v backend do not have mappings to functional units
Date: Thu, 20 Apr 2023 14:50:17 +0000	[thread overview]
Message-ID: <bug-108248-4-cuYD9e0d2Z@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-108248-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108248

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jeff Law <law@gcc.gnu.org>:

https://gcc.gnu.org/g:07e2576d6f344acab338deeb051845c90c1cf6a3

commit r14-116-g07e2576d6f344acab338deeb051845c90c1cf6a3
Author: Raphael Zinsly <rzinsly@ventanamicro.com>
Date:   Thu Apr 20 08:48:08 2023 -0600

    [PR target/108248] [RISC-V] Break down some bitmanip insn types

    This is primarily Raphael's work.  All I did was adjust it to apply to the
    trunk and add the new types to generic.md's scheduling model.

    The basic idea here is to make sure we have the ability to schedule the
    bitmanip instructions with a finer degree of control.  Some of the bitmanip
    instructions are likely to have differing scheduler characteristics across
    different implementations.

    So rather than assign these instructions a generic "bitmanip" type, this
    patch assigns them a type based on their RTL code by using the
<bitmanip_insn>
    iterator for the type.  Naturally we have to add a few new types.  It
affects
    clz, ctz, cpop, min, max.

    We didn't do this for things like shNadd, single bit manipulation, etc. We
    certainly could if the needs presents itself.

    I threw all the new types into the generic_alu bucket in the generic
    scheduling model.  Seems as good a place as any. Someone who knows the
    sifive uarch should probably add these types (and bitmanip) to the sifive
    scheduling model.

    We also noticed that the recently added orc.b didn't have a type at all.
    So we added it as a generic bitmanip type.

    This has been bootstrapped in a gcc-12 base and I've built and run the
    testsuite without regressions on the trunk.

    Given it was primarily Raphael's work I could probably approve & commit it.
    But I'd like to give the other RISC-V folks a chance to chime in.

            PR target/108248
    gcc/
            * config/riscv/bitmanip.md (clz, ctz, pcnt, min, max patterns): Use
            <bitmanip_insn> as the type to allow for fine grained control of
            scheduling these insns.
            * config/riscv/generic.md (generic_alu): Add bitmanip, clz, ctz,
pcnt,
            min, max.
            * config/riscv/riscv.md (type attribute): Add types for clz, ctz,
            pcnt, signed and unsigned min/max.

  parent reply	other threads:[~2023-04-20 14:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-28 20:41 [Bug target/108248] New: " law at gcc dot gnu.org
2022-12-29  0:47 ` [Bug target/108248] " andrew at sifive dot com
2022-12-29  1:28 ` law at gcc dot gnu.org
2022-12-29  1:49 ` andrew at sifive dot com
2022-12-29  2:08 ` law at gcc dot gnu.org
2023-02-22  2:22 ` law at gcc dot gnu.org
2023-02-22  6:49 ` pinskia at gcc dot gnu.org
2023-04-20 14:50 ` cvs-commit at gcc dot gnu.org [this message]
2023-04-20 14:50 ` law at gcc dot gnu.org

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=bug-108248-4-cuYD9e0d2Z@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).