public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Uros Bizjak <ubizjak@gmail.com>
To: GCC Patches <gcc-patches@gcc.gnu.org>
Cc: Roger Sayle <roger@nextmovesoftware.com>,
	 Richard Sandiford <richard.sandiford@arm.com>
Subject: Re: [x86 PATCH] PR rtl-optimization/107991: peephole2 to tweak register allocation.
Date: Mon, 9 Jan 2023 17:02:58 +0100	[thread overview]
Message-ID: <CAFULd4Y=9ZM16ZWpKEc4gK3fVyTRbRSyzvXZLrDrFEOn+OhBtA@mail.gmail.com> (raw)
In-Reply-To: <011401d9243b$3782ce10$a6886a30$@nextmovesoftware.com>

On Mon, Jan 9, 2023 at 4:01 PM Roger Sayle <roger@nextmovesoftware.com> wrote:
>
>
> This patch addresses PR rtl-optimization/107991, which is a P2 regression
> where GCC currently requires more "mov" instructions than GCC 7.
>
> The x86's two address ISA creates some interesting challenges for reload.
> For example, the tricky "x = y - x" usually needs to be implemented on x86
> as
>
>         tmp = x
>         x = y
>         x -= tmp
>
> where a scratch register and two mov's are required to work around
> the lack of a subf (subtract from) or rsub (reverse subtract) insn.
>
> Not uncommonly, if y is dead after this subtraction, register allocation
> can be improved by clobbering y.
>
>         y -= x
>         x = y
>
> For the testcase in PR 107991, things are slightly more complicated,
> where y is not itself dead, but is assigned from (i.e. equivalent to)
> a value that is dead.  Hence we have something like:
>
>         y = z
>         x = y - x
>
> so, GCC's reload currently generates the expected shuffle (as y is live):
>
>         y = z
>         tmp = x
>         x = y
>         x -= tmp
>
> but we can use a peephole2 that understands that y and z are equivalent,
> and that z is dead, to produce the shorter sequence:
>
>         y = z
>         z -= x
>         x = z
>
> In practice, for the new testcase from PR 107991, which before produced:
>
> foo:    movl    %edx, %ecx
>         movl    %esi, %edx
>         movl    %esi, %eax
>         subl    %ecx, %edx
>         testb   %dil, %dil
>         cmovne  %edx, %eax
>         ret
>
> with this patch/peephole2 we now produce the much improved:
>
> foo:    movl    %esi, %eax
>         subl    %edx, %esi
>         testb   %dil, %dil
>         cmovne  %esi, %eax
>         ret
>
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> and make -k check, both with and without --target_board=unix{-m32},
> with no new failures.  Ok for mainline?

Looking at the PR, it looks to me that Richard S (CC'd) wants to solve
this issue in the register allocator. This would be preferred
(compared to a very specialized peephole2), since peephole2 pass comes
very late in the game, so one freed register does not contribute to
lower the register pressure at all.

Peephole2 should be used to clean after reload only in rare cases when
target ISA prevents generic solution. From your description, a generic
solution would benefit all targets with destructive subtraction (or
perhaps also for other noncommutative operations).

So, please coordinate with Richard S regarding this issue.

Thanks,
Uros.

>
>
> 2023-01-09  Roger Sayle  <roger@nextmovesoftware.com>
>
> gcc/ChangeLog
>         PR rtl-optimization/107991
>         * config/i386/i386.md (peephole2): New peephole2 to avoid register
>         shuffling before a subtraction, after a register-to-register move.
>
> gcc/testsuite/ChangeLog
>         PR rtl-optimization/107991
>         * gcc.target/i386/pr107991.c: New test case.
>
>
> Thanks in advance,
> Roger
> --
>

  reply	other threads:[~2023-01-09 16:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-09 15:01 Roger Sayle
2023-01-09 16:02 ` Uros Bizjak [this message]
2023-01-10 10:48   ` Richard Sandiford
2023-01-10 15:01     ` Roger Sayle
2023-01-11  9:28       ` Uros Bizjak

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='CAFULd4Y=9ZM16ZWpKEc4gK3fVyTRbRSyzvXZLrDrFEOn+OhBtA@mail.gmail.com' \
    --to=ubizjak@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.sandiford@arm.com \
    --cc=roger@nextmovesoftware.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).