public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Vladimir Makarov <vmakarov@redhat.com>
To: Richard Sandiford <richard.sandiford@arm.com>,
	jlaw@ventanamicro.com, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH 0/5] Add support for operand-specific alignment requirements
Date: Mon, 13 Nov 2023 19:01:10 -0500	[thread overview]
Message-ID: <5777a683-4536-4561-e861-4e53dfd18318@redhat.com> (raw)
In-Reply-To: <20231112145229.2924713-1-richard.sandiford@arm.com>


On 11/12/23 09:52, Richard Sandiford wrote:
> SME has various instructions that require aligned register tuples.
> However, the associated tuple modes are already widely used and do
> not need to be aligned in other contexts.  It therefore isn't
> appropriate to force alignment in TARGET_HARD_REGNO_MODE_OK.
>
> There are also strided loads and stores that require:
>
> - (regno & 0x8) == 0 for 2-register tuples
> - (regno & 0xc) == 0 for 4-register tuples
>
> Although the requirements for strided loads and stores could be
> enforced by C++ conditions on the insn, it's convenient to handle
> them in the same way as alignment.
>
> This series of patches therefore adds a way for register constraints
> to specify which start registers are valid and which aren't.  Most of
> the details are in the covering note to the first patch.
>
> This is clearly changing a performance-sensitive part of the compiler.
> I've tried to ensure that the overhead is only small for targets that
> use the new feature.  Almost all of the new code gets optimised away
> on targets that don't use the feature.
>
> Richard Sandiford (5):
>    Add register filter operand to define_register_constraint
>    recog: Handle register filters
>    lra: Handle register filters
>    ira: Handle register filters
>    Add an aligned_register_operand predicate
>
>   gcc/common.md          |  28 ++++++++
>   gcc/doc/md.texi        |  41 +++++++++++-
>   gcc/doc/tm.texi        |   3 +-
>   gcc/doc/tm.texi.in     |   3 +-
>   gcc/genconfig.cc       |   2 +
>   gcc/genpreds.cc        | 146 ++++++++++++++++++++++++++++++++++++++++-
>   gcc/gensupport.cc      |  48 +++++++++++++-
>   gcc/gensupport.h       |   3 +
>   gcc/ira-build.cc       |   8 +++
>   gcc/ira-color.cc       |  10 +++
>   gcc/ira-int.h          |  14 ++++
>   gcc/ira-lives.cc       |  61 +++++++++++++++++
>   gcc/lra-constraints.cc |  13 +++-
>   gcc/recog.cc           |  14 +++-
>   gcc/recog.h            |  24 ++++++-
>   gcc/reginfo.cc         |   5 ++
>   gcc/rtl.def            |   6 +-
>   gcc/target-globals.cc  |   6 +-
>   gcc/target-globals.h   |   3 +
>   19 files changed, 421 insertions(+), 17 deletions(-)
>
Collecting all occurrence constraints for IRA probably might result in 
worse allocation (when pseudo is spilled because of this) in comparison 
with using wider hard reg set and generating reload insns for some 
pseudo occurrences requiring stricter constraints.  Regional RA 
mitigates this issue.  In any case IRA changes is an improvement in 
comparison with using only hard_regno_mode_ok.  Using smaller 
constraints in certain cases for pseudos spilled after using the biggest 
constraint is just an idea for further RA improvement for targets using 
the filters. The only question is it worth to implement.

All IRA/LRA/reginfo patches are OK for me.  IMHO other changes are 
pretty strait forward not to ask somebody to review them.

Thank you, Richard.



  parent reply	other threads:[~2023-11-14  0:01 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-12 14:52 Richard Sandiford
2023-11-12 14:52 ` [PATCH 1/5] Add register filter operand to define_register_constraint Richard Sandiford
2023-11-19 21:49   ` Jeff Law
2023-11-12 14:52 ` [PATCH 2/5] recog: Handle register filters Richard Sandiford
2023-11-19 21:51   ` Jeff Law
2023-11-12 14:52 ` [PATCH 3/5] lra: " Richard Sandiford
2023-11-12 14:52 ` [PATCH 4/5] ira: " Richard Sandiford
2023-11-12 14:52 ` [PATCH 5/5] Add an aligned_register_operand predicate Richard Sandiford
2023-11-19 21:52   ` Jeff Law
2023-11-14  0:01 ` Vladimir Makarov [this message]
2023-11-22  9:47 [PATCH 0/5] Add support for operand-specific alignment requirements juzhe.zhong
2023-11-22 10:08 ` Richard Sandiford
2023-11-22 22:32   ` 钟居哲
2023-11-23 18:18     ` Richard Sandiford
2023-11-24  6:42       ` juzhe.zhong
2023-11-24  9:55         ` Richard Sandiford

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=5777a683-4536-4561-e861-4e53dfd18318@redhat.com \
    --to=vmakarov@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jlaw@ventanamicro.com \
    --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).