From: Victor Do Nascimento <victor.donascimento@arm.com>
To: <gcc-patches@gcc.gnu.org>
Cc: <richard.sandiford@arm.com>, <Richard.Earnshaw@arm.com>,
"Victor Do Nascimento" <victor.donascimento@arm.com>
Subject: [PATCH 00/10] Make `dot_prod' a convert-type optab
Date: Wed, 10 Jul 2024 15:05:53 +0100 [thread overview]
Message-ID: <20240710140602.1707875-1-victor.donascimento@arm.com> (raw)
Given the specification in the GCC internals manual defines the
{u|s}dot_prod<m> standard name as taking "two signed elements of the
same mode, adding them to a third operand of wider mode", there is
currently ambiguity in the relationship between the mode of the first
two arguments and that of the third.
This vagueness means that, in theory, different modes may be
supportable in the third argument. This flexibility would allow for a
given backend to add to the accumulator a different number of
vectorized products, e.g. A backend may provide instructions for both:
accum += a[0] * b[0] + a[1] * b[1] + a[2] * b[2] + a[3] * b[3]
and
accum += a[0] * b[0] + a[1] * b[1],
as is now seen in the SVE2.1 extension to AArch64. In spite of the
aforementioned flexibility, modeling the dot-product operation as a
direct optab means that we have no way to encode both input and the
accumulator data modes into the backend pattern name, which prevents
us from harnessing this flexibility.
The purpose of this patch-series is therefore to remedy this current
shortcoming, moving the `dot_prod' from its current implementation as
a direct optab to an implementation where, as a conversion optab, we
are able to differentiate between dot products taking the same input
mode but resulting in a different output mode.
Regression-tested on x86_64, aarch64 and armhf. I'd appreciate help
running relevant tests on the remaining architectures, i.e. arc, mips,
altivec and c6x to ensure I've not inadvertently broken anything for
those backends.
Victor Do Nascimento (10):
optabs: Make all `*dot_prod_optab's modeled as conversions
autovectorizer: Add basic support for convert optabs
aarch64: Fix aarch64 backend-use of (u|s|us)dot_prod patterns.
arm: Fix arm backend-use of (u|s|us)dot_prod patterns.
i386: Fix dot_prod backend patterns for mmx and sse targets
arc: Adjust dot-product backend patterns
mips: Adjust dot-product backend patterns
altivec: Adjust dot-product backend patterns
c6x: Adjust dot-product backend patterns
autovectorizer: Test autovectorization of different dot-prod modes.
gcc/config/aarch64/aarch64-builtins.cc | 71 ++++++++++++++
gcc/config/aarch64/aarch64-simd-builtins.def | 4 -
gcc/config/aarch64/aarch64-simd.md | 9 +-
.../aarch64/aarch64-sve-builtins-base.cc | 13 +--
gcc/config/aarch64/aarch64-sve-builtins.cc | 17 ++++
gcc/config/aarch64/aarch64-sve-builtins.h | 3 +
gcc/config/aarch64/aarch64-sve.md | 6 +-
gcc/config/aarch64/aarch64-sve2.md | 2 +-
gcc/config/aarch64/iterators.md | 1 +
gcc/config/arc/simdext.md | 8 +-
gcc/config/arm/arm-builtins.cc | 95 +++++++++++++++++++
gcc/config/arm/arm-protos.h | 3 +
gcc/config/arm/arm.cc | 1 +
gcc/config/arm/arm_neon_builtins.def | 3 -
gcc/config/arm/neon.md | 4 +-
gcc/config/c6x/c6x.md | 2 +-
gcc/config/i386/mmx.md | 30 +++---
gcc/config/i386/sse.md | 47 +++++----
gcc/config/mips/loongson-mmi.md | 2 +-
gcc/config/rs6000/altivec.md | 4 +-
gcc/doc/md.texi | 18 ++--
gcc/gimple-match-exports.cc | 18 ++++
gcc/gimple-match.h | 2 +
gcc/optabs.cc | 3 +-
gcc/optabs.def | 6 +-
.../gcc.dg/vect/vect-dotprod-twoway.c | 38 ++++++++
.../aarch64/sme/vect-dotprod-twoway.c | 25 +++++
gcc/tree-vect-loop.cc | 1 +
gcc/tree-vect-patterns.cc | 43 ++++++++-
29 files changed, 399 insertions(+), 80 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/vect/vect-dotprod-twoway.c
create mode 100644 gcc/testsuite/gcc.target/aarch64/sme/vect-dotprod-twoway.c
--
2.34.1
next reply other threads:[~2024-07-10 14:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 14:05 Victor Do Nascimento [this message]
2024-07-10 14:05 ` [PATCH 01/10] optabs: Make all `*dot_prod_optab's modeled as conversions Victor Do Nascimento
2024-07-11 14:16 ` Richard Sandiford
2024-07-10 14:05 ` [PATCH 02/10] autovectorizer: Add basic support for convert optabs Victor Do Nascimento
2024-07-11 7:15 ` Tamar Christina
2024-07-10 14:05 ` [PATCH 03/10] aarch64: Fix aarch64 backend-use of (u|s|us)dot_prod patterns Victor Do Nascimento
2024-07-11 7:24 ` Kyrylo Tkachov
2024-07-11 13:41 ` Richard Sandiford
2024-07-11 14:04 ` Kyrylo Tkachov
2024-07-10 14:05 ` [PATCH 04/10] arm: Fix arm " Victor Do Nascimento
2024-07-10 14:05 ` [PATCH 05/10] i386: Fix dot_prod backend patterns for mmx and sse targets Victor Do Nascimento
2024-07-11 1:45 ` Hongtao Liu
2024-07-12 2:23 ` Jiang, Haochen
2024-07-12 10:15 ` Victor Do Nascimento
2024-07-10 14:05 ` [PATCH 06/10] arc: Adjust dot-product backend patterns Victor Do Nascimento
2024-07-10 14:06 ` [PATCH 07/10] mips: " Victor Do Nascimento
2024-07-10 14:06 ` [PATCH 08/10] altivec: " Victor Do Nascimento
2024-07-10 14:06 ` [PATCH 09/10] c6x: " Victor Do Nascimento
2024-07-10 14:06 ` [PATCH 10/10] autovectorizer: Test autovectorization of different dot-prod modes Victor Do Nascimento
2024-07-11 7:02 ` Tamar Christina
2024-07-11 8:47 ` Richard Biener
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=20240710140602.1707875-1-victor.donascimento@arm.com \
--to=victor.donascimento@arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.sandiford@arm.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).