public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Christophe Lyon <christophe.lyon@arm.com>
To: Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	Richard Earnshaw <Richard.Earnshaw@arm.com>,
	Richard Sandiford <Richard.Sandiford@arm.com>
Subject: Re: [PATCH 00/22] arm: New framework for MVE intrinsics
Date: Wed, 3 May 2023 17:01:02 +0200	[thread overview]
Message-ID: <7894e075-2945-1343-2cd5-5856e2e3f95b@arm.com> (raw)
In-Reply-To: <3ae3da58-0cdd-3657-8a7f-00c08c3b1e54@arm.com>



On 5/2/23 17:04, Christophe Lyon via Gcc-patches wrote:
> 
> 
> On 5/2/23 11:18, Kyrylo Tkachov wrote:
>> Hi Christophe,
>>
>>> -----Original Message-----
>>> From: Christophe Lyon <christophe.lyon@arm.com>
>>> Sent: Tuesday, April 18, 2023 2:46 PM
>>> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov <Kyrylo.Tkachov@arm.com>;
>>> Richard Earnshaw <Richard.Earnshaw@arm.com>; Richard Sandiford
>>> <Richard.Sandiford@arm.com>
>>> Cc: Christophe Lyon <Christophe.Lyon@arm.com>
>>> Subject: [PATCH 00/22] arm: New framework for MVE intrinsics
>>>
>>> Hi,
>>>
>>> This is the beginning of a long patch series to change the way Arm MVE
>>> intrinsics are implemented. The goal is to get rid of arm_mve.h, which
>>> takes a long time to parse and compile.
>>>
>>
>> Thanks for doing this. It is a significant improvement to the MVE 
>> intrinsics and should address some of the biggest maintainability and 
>> scalability issues we have in that area.
>> I'll be going through the patches one-by-one (I've looked at these 
>> offline already before), but the approach looks good to me at a high 
>> level.
>>
>> My hope is that we'll move all the intrinsics, including the Neon ones 
>> to use this framework in the future, but getting the framework in 
>> place first is a good major first step in that direction.
>>
> 
> Indeed. Ideally we'd probably want to make this framework more generic 
> so that it supports aarch64 SVE, arm MVE and Neon, but that can be done 
> later. I tried to highlight the differences I noticed compared to SVE, 
> so that it helps us think what needs to be specialized for different 
> targets, as opposed to what is already generic enough.
> 
> Thanks,
> 
> Christophe
> 

Thank you Kyrill for the quick review.
I've pushed the series with the minor changes you requested.

I am going to prepare the next batch :-)

Thanks,

Christophe

>> Thanks,
>> Kyrill
>>
>>> Roughly speaking, it's about using a framework very similar to what is
>>> implemented for AArch64/SVE intrinsics. I haven't converted all the
>>> intrinsics yet, but I think it would be good to start the conversion
>>> when stage-1 reopens.
>>>
>>> * Factorizing names
>>> One of the main implementation differences I noticed between SVE and
>>> MVE is that mve.md provides only full builtin names at the moment, and
>>> makes almost no use of "parameterized names"
>>> (https://gcc.gnu.org/onlinedocs/gccint/Parameterized-
>>> Names.html#Parameterized-Names).
>>>
>>> Without this, we'd need the builtin expander to use a large
>>> switch/case of the form:
>>>
>>> switch (code)
>>> case VADDQ_S: insn_code = code_for_mve_vaddq_s (...)
>>> case VADDQ_U: insn_code = code_for_mve_vaddq_u (...)
>>> case VSUBQ_S: insn_code = code_for_mve_vsubq_s (...)
>>> case VSUBQ_U: insn_code = code_for_mve_vsubq_u (...)
>>> ....
>>>
>>> so part of the work (which I called "factorize" in the commit
>>> messages) is about replacing
>>>
>>> (define_insn "mve_vaddq_n_<supf><mode>"
>>> with
>>> (define_insn "@mve_<mve_insn>q_n_<supf><mode>"
>>> with the help of a new iterator (mve_insn).
>>>
>>> Doing so makes it more obvious that some patterns are identical,
>>> except for the instruction name. I took this opportunity to merge
>>> them, so for instance I have a patch which merges add, sub and mul
>>> patterns.  Although not strictly necessary for the MVE intrinsics
>>> restructuring work, this is a good opportunity to reduce such code
>>> duplication (I did notice a few bugs during that process, which led me
>>> to post a few small patches in the past months).  Note that identical
>>> patterns will probably remain after the series, they can be merged
>>> later if we want.
>>>
>>> This factorization also implies the introduction of new iterators, but
>>> also means that several existing ones become useless. These patches do
>>> not remove them because it's a bit painful to reorder patches which
>>> remove lines at some "random" places, leading to merge conflicts. It's
>>> much simpler to write a big cleanup patch at the end of the serie to
>>> remove all such useless iterators at once.
>>>
>>> * Intrinsic re-implementation
>>> After intrinsic names have been factorized, the actual
>>> re-implementation patch is small:
>>> - add 1 line in each of arm-mve-builtins-base.{cc,def,h} describing
>>>    the intrinsic shape/signature, types and predicates involved,
>>>    RTX/unspec codes
>>> - remove the intrinsic definitions from arm_mve.h
>>>
>>> The full series of ~140 patches is organized like this:
>>> - patches 1 and 2 introduce the new framework
>>> - new implementation of vreinterpretq
>>> - new implementation of vuninitialized
>>> - patch groups of varying size, consisting in:
>>>    - add a new "shape" if needed (e.g. unary, binary, ternary, ....)
>>>    - add framework support functions if needed
>>>    - factorize a set of intrinsics (at minimum, just make use of
>>>      parameterized-names)
>>>    - actual re-implementation of the intrinsics
>>>
>>> I kept patches small so the incremental progress is easy to follow and
>>> check.  I'll submit the patches in small groups, this first one will
>>> make sure we agree on the implementation.
>>>
>>> Tested on arm-eabi with -mthumb/-mfloat-abi=hard/-march=armv8.1-
>>> m.main+mve.
>>>
>>> To help reviewers, I suggest to compare arm-mve-builtins.cc with
>>> aarch64-sve-builtins.cc.
>>>
>>> Christophe Lyon (22):
>>>    arm: move builtin function codes into general numberspace
>>>    arm: [MVE intrinsics] Add new framework
>>>    arm: [MVE intrinsics] Rework vreinterpretq
>>>    arm: [MVE intrinsics] Rework vuninitialized
>>>    arm: [MVE intrinsics] add binary_opt_n shape
>>>    arm: [MVE intrinsics] add unspec_based_mve_function_exact_insn
>>>    arm: [MVE intrinsics] factorize vadd vsubq vmulq
>>>    arm: [MVE intrinsics] rework vaddq vmulq vsubq
>>>    arm: [MVE intrinsics] add binary shape
>>>    arm: [MVE intrinsics] factorize vandq veorq vorrq vbicq
>>>    arm: [MVE intrinsics] rework vandq veorq
>>>    arm: [MVE intrinsics] add binary_orrq shape
>>>    arm: [MVE intrinsics] rework vorrq
>>>    arm: [MVE intrinsics] add unspec_mve_function_exact_insn
>>>    arm: [MVE intrinsics] add create shape
>>>    arm: [MVE intrinsics] factorize vcreateq
>>>    arm: [MVE intrinsics] rework vcreateq
>>>    arm: [MVE intrinsics] factorize several binary_m operations
>>>    arm: [MVE intrinsics] factorize several binary _n operations
>>>    arm: [MVE intrinsics] factorize several binary _m_n operations
>>>    arm: [MVE intrinsics] factorize several binary operations
>>>    arm: [MVE intrinsics] rework vhaddq vhsubq vmulhq vqaddq vqsubq
>>>      vqdmulhq vrhaddq vrmulhq
>>>
>>>   gcc/config.gcc                                |    2 +-
>>>   gcc/config/arm/arm-builtins.cc                |  237 +-
>>>   gcc/config/arm/arm-builtins.h                 |    1 +
>>>   gcc/config/arm/arm-c.cc                       |   42 +-
>>>   gcc/config/arm/arm-mve-builtins-base.cc       |  163 +
>>>   gcc/config/arm/arm-mve-builtins-base.def      |   50 +
>>>   gcc/config/arm/arm-mve-builtins-base.h        |   47 +
>>>   gcc/config/arm/arm-mve-builtins-functions.h   |  387 +
>>>   gcc/config/arm/arm-mve-builtins-shapes.cc     |  529 ++
>>>   gcc/config/arm/arm-mve-builtins-shapes.h      |   47 +
>>>   gcc/config/arm/arm-mve-builtins.cc            | 2013 ++++-
>>>   gcc/config/arm/arm-mve-builtins.def           |   40 +-
>>>   gcc/config/arm/arm-mve-builtins.h             |  672 +-
>>>   gcc/config/arm/arm-protos.h                   |   24 +
>>>   gcc/config/arm/arm.cc                         |   27 +
>>>   gcc/config/arm/arm_mve.h                      | 7581 +----------------
>>>   gcc/config/arm/arm_mve_builtins.def           |    6 -
>>>   gcc/config/arm/arm_mve_types.h                | 1430 ----
>>>   gcc/config/arm/iterators.md                   |  240 +-
>>>   gcc/config/arm/mve.md                         | 1747 +---
>>>   gcc/config/arm/predicates.md                  |    4 +
>>>   gcc/config/arm/t-arm                          |   32 +-
>>>   gcc/config/arm/unspecs.md                     |    1 +
>>>   gcc/config/arm/vec-common.md                  |    8 +-
>>>   gcc/testsuite/g++.target/arm/mve.exp          |    8 +-
>>>   .../arm/mve/general-c++/nomve_fp_1.c          |   15 +
>>>   .../arm/mve/general-c++/vreinterpretq_1.C     |   25 +
>>>   .../gcc.target/arm/mve/general-c/nomve_fp_1.c |   15 +
>>>   .../arm/mve/general-c/vreinterpretq_1.c       |   25 +
>>>   29 files changed, 4926 insertions(+), 10492 deletions(-)
>>>   create mode 100644 gcc/config/arm/arm-mve-builtins-base.cc
>>>   create mode 100644 gcc/config/arm/arm-mve-builtins-base.def
>>>   create mode 100644 gcc/config/arm/arm-mve-builtins-base.h
>>>   create mode 100644 gcc/config/arm/arm-mve-builtins-functions.h
>>>   create mode 100644 gcc/config/arm/arm-mve-builtins-shapes.cc
>>>   create mode 100644 gcc/config/arm/arm-mve-builtins-shapes.h
>>>   create mode 100644 gcc/testsuite/g++.target/arm/mve/general-
>>> c++/nomve_fp_1.c
>>>   create mode 100644 gcc/testsuite/g++.target/arm/mve/general-
>>> c++/vreinterpretq_1.C
>>>   create mode 100644 gcc/testsuite/gcc.target/arm/mve/general-
>>> c/nomve_fp_1.c
>>>   create mode 100644 gcc/testsuite/gcc.target/arm/mve/general-
>>> c/vreinterpretq_1.c
>>>
>>> -- 
>>> 2.34.1
>>

      reply	other threads:[~2023-05-03 15:01 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-18 13:45 Christophe Lyon
2023-04-18 13:45 ` [PATCH 01/22] arm: move builtin function codes into general numberspace Christophe Lyon
2023-05-02  9:24   ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 02/22] arm: [MVE intrinsics] Add new framework Christophe Lyon
2023-05-02 10:17   ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 03/22] arm: [MVE intrinsics] Rework vreinterpretq Christophe Lyon
2023-05-02 10:26   ` Kyrylo Tkachov
2023-05-02 14:05     ` Christophe Lyon
2023-05-02 15:28       ` Kyrylo Tkachov
2023-05-02 15:49         ` Christophe Lyon
2023-05-03 14:37           ` [PATCH v2 " Christophe Lyon
2023-05-03 14:52             ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 04/22] arm: [MVE intrinsics] Rework vuninitialized Christophe Lyon
2023-05-02 16:13   ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 05/22] arm: [MVE intrinsics] add binary_opt_n shape Christophe Lyon
2023-05-02 16:16   ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 06/22] arm: [MVE intrinsics] add unspec_based_mve_function_exact_insn Christophe Lyon
2023-05-02 16:17   ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 07/22] arm: [MVE intrinsics] factorize vadd vsubq vmulq Christophe Lyon
2023-05-02 16:19   ` Kyrylo Tkachov
2023-05-02 16:22     ` Christophe Lyon
2023-04-18 13:45 ` [PATCH 08/22] arm: [MVE intrinsics] rework vaddq vmulq vsubq Christophe Lyon
2023-05-02 16:31   ` Kyrylo Tkachov
2023-05-03  9:06     ` Christophe Lyon
2023-04-18 13:45 ` [PATCH 09/22] arm: [MVE intrinsics] add binary shape Christophe Lyon
2023-05-02 16:32   ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 10/22] arm: [MVE intrinsics] factorize vandq veorq vorrq vbicq Christophe Lyon
2023-05-02 16:36   ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 11/22] arm: [MVE intrinsics] rework vandq veorq Christophe Lyon
2023-05-02 16:37   ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 12/22] arm: [MVE intrinsics] add binary_orrq shape Christophe Lyon
2023-05-02 16:39   ` Kyrylo Tkachov
2023-04-18 13:45 ` [PATCH 13/22] arm: [MVE intrinsics] rework vorrq Christophe Lyon
2023-05-02 16:41   ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 14/22] arm: [MVE intrinsics] add unspec_mve_function_exact_insn Christophe Lyon
2023-05-03  8:40   ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 15/22] arm: [MVE intrinsics] add create shape Christophe Lyon
2023-05-03  8:40   ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 16/22] arm: [MVE intrinsics] factorize vcreateq Christophe Lyon
2023-05-03  8:42   ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 17/22] arm: [MVE intrinsics] rework vcreateq Christophe Lyon
2023-05-03  8:44   ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 18/22] arm: [MVE intrinsics] factorize several binary_m operations Christophe Lyon
2023-05-03  8:46   ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 19/22] arm: [MVE intrinsics] factorize several binary _n operations Christophe Lyon
2023-05-03  8:47   ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 20/22] arm: [MVE intrinsics] factorize several binary _m_n operations Christophe Lyon
2023-05-03  8:48   ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 21/22] arm: [MVE intrinsics] factorize several binary operations Christophe Lyon
2023-05-03  8:49   ` Kyrylo Tkachov
2023-04-18 13:46 ` [PATCH 22/22] arm: [MVE intrinsics] rework vhaddq vhsubq vmulhq vqaddq vqsubq vqdmulhq vrhaddq vrmulhq Christophe Lyon
2023-05-03  8:51   ` Kyrylo Tkachov
2023-05-02  9:18 ` [PATCH 00/22] arm: New framework for MVE intrinsics Kyrylo Tkachov
2023-05-02 15:04   ` Christophe Lyon
2023-05-03 15:01     ` Christophe Lyon [this message]

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=7894e075-2945-1343-2cd5-5856e2e3f95b@arm.com \
    --to=christophe.lyon@arm.com \
    --cc=Kyrylo.Tkachov@arm.com \
    --cc=Richard.Earnshaw@arm.com \
    --cc=Richard.Sandiford@arm.com \
    --cc=gcc-patches@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).