From: Uros Bizjak <ubizjak@gmail.com>
To: Roger Sayle <roger@nextmovesoftware.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] x86_64: Use peephole2 to eliminate redundant moves.
Date: Tue, 11 Aug 2020 12:14:08 +0200 [thread overview]
Message-ID: <CAFULd4ZgBV9oJaD414RtTt+K7TB1kQvMRCWGeaLS6WAzkH6naA@mail.gmail.com> (raw)
In-Reply-To: <001001d66fb1$e1e95c70$a5bc1550$@nextmovesoftware.com>
On Tue, Aug 11, 2020 at 9:34 AM Roger Sayle <roger@nextmovesoftware.com> wrote:
>
>
> The recent fix for mul_widen_cost revealed an interesting
> quirk of ira/reload register allocation on x86_64. As shown in
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551648.html
> for gcc.target/i386/pr71321.c we generate the following code that
> performs unnecessary register shuffling.
>
> movl $-51, %edx
> movl %edx, %eax
> mulb %dil
>
> which is caused by reload generating the following instructions
> (notice the set of the first register is dead in the 2nd insn):
>
> (insn 7 4 36 2 (set (reg:QI 1 dx [94])
> (const_int -51 [0xffffffffffffffcd])) {*movqi_internal}
> (expr_list:REG_EQUIV (const_int -51 [0xffffffffffffffcd])
> (nil)))
> (insn 36 7 8 2 (set (reg:QI 0 ax [93])
> (reg:QI 1 dx [94])) {*movqi_internal}
> (expr_list:REG_DEAD (reg:QI 1 dx [94])
> (nil)))
>
> Various discussions in bugzilla seem to point to reload preferring
> not to load constants directly into CLASS_LIKELY_SPILLED_P registers.
This can extend the lifetime of a register over the instruction that
needs one of the CLASS_LIKELY_SPILLED_P registers. Various MUL, DIV
and even shift insns were able to choke the allocator for x86 targets,
so this is a small price to pay to avoid regalloc failure.
> Whatever the cause, one solution (workaround), that doesn't involve
> rewriting a register allocator, is to use peephole2 to spot this
> weirdness and eliminate it. In fact, this use case is (probably)
> the reason peephole optimizers were originally developed, but it's
> a little disappointing this application of them is still required
> today. On a positive note, this clean-up is cheap, as we're already
> traversing the instruction stream with liveness (REG_DEAD notes)
> already calculated.
>
> With this peephole2 the above three instructions (from pr71321.c)
> are replaced with:
>
> movl $-51, %eax
> mulb %dil
>
> This patch has been tested on x86_64-pc-linux-gnu with "make bootstrap"
> and "make -k check" with no new failures. This peephole triggers
> 1435 during stage2 and stage3 of a bootstrap, and a further 1274
> times during "make check". The most common case is DX_REG->AX_REG
> (as above) which occurs 421 times. I've restricted this pattern to
> immediate constant loads into general operand registers, which fixes
> this particular problem, but broader predicates may help similar cases.
> Ok for mainline?
>
> 2020-08-11 Roger Sayle <roger@nextmovesoftware.com>
>
> * config/i386/i386.md (peephole2): Reduce unnecessary
> register shuffling produced by register allocation.
LGTM, but I wonder if the allocator is also too conservative with
memory operands. Perhaps x86_64_general_operand can be used here.
Uros.
>
> Thanks in advance,
> Roger
> --
> Roger Sayle
> NextMove Software
> Cambridge, UK
>
next prev parent reply other threads:[~2020-08-11 10:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 7:34 Roger Sayle
2020-08-11 10:14 ` Uros Bizjak [this message]
2020-08-12 7:55 ` Roger Sayle
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=CAFULd4ZgBV9oJaD414RtTt+K7TB1kQvMRCWGeaLS6WAzkH6naA@mail.gmail.com \
--to=ubizjak@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--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).