public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Roger Sayle <sayle@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r12-1668] PR target/11877: Use xor to write zero to memory with -Os Date: Mon, 21 Jun 2021 07:56:38 +0000 (GMT) [thread overview] Message-ID: <20210621075638.161833886C6C@sourceware.org> (raw) https://gcc.gnu.org/g:9cedbaab8e048b90ceb9ceef0d851385fae67cde commit r12-1668-g9cedbaab8e048b90ceb9ceef0d851385fae67cde Author: Roger Sayle <roger@nextmovesoftware.com> Date: Mon Jun 21 08:54:50 2021 +0100 PR target/11877: Use xor to write zero to memory with -Os The following patch attempts to resolve PR target/11877 (without triggering PR/23102). On x86_64, writing an SImode or DImode zero to memory uses an instruction encoding that is larger than first clearing a register (using xor) then writing that to memory. Hence, after reload, the peephole2 pass can determine if there's a suitable free register, and if so, use that to shrink the code size with -Os. To improve code size, and avoid inserting a large number of xor instructions (PR target/23102), this patch makes use of peephole2's efficient pattern matching to use a single temporary for a run of consecutive writes. In theory, one could do better still with a new target-specific pass, gated on -Os, to shrink these instructions (like stv), but that's probably overkill for the little remaining space savings. Evaluating this patch on the CSiBE benchmark (v2.1.1) results in a 0.26% code size improvement (3715273 bytes down to 3705477) on x86_64 with -Os [saving 1 byte every 400]. 549 of 894 tests improve, two tests grow larger. Analysis of these 2 pathological cases reveals that although peephole2's match_scratch prefers to use a call-clobbered register (to avoid requiring a new stack frame), very rarely this interacts with GCC's shrink wrapping optimization, which may previously have avoided saving/restoring a call clobbered register, such as %eax, in the calling function. 2021-06-21 Roger Sayle <roger@nextmovesoftware.com> gcc/ChangeLog PR target/11877 * config/i386/i386.md: New define_peephole2s to shrink writing 1, 2 or 4 consecutive zeros to memory when optimizing for size. gcc/testsuite/ChangeLog PR target/11877 * gcc.target/i386/pr11877.c: New test case. Diff: --- gcc/config/i386/i386.md | 36 +++++++++++++++++++++++++++++++++ gcc/testsuite/gcc.target/i386/pr11877.c | 16 +++++++++++++++ 2 files changed, 52 insertions(+) diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md index 48532eb7ddf..2333261a894 100644 --- a/gcc/config/i386/i386.md +++ b/gcc/config/i386/i386.md @@ -19357,6 +19357,42 @@ ix86_expand_clear (operands[1]); }) +;; When optimizing for size, zeroing memory should use a register. +(define_peephole2 + [(match_scratch:SWI48 0 "r") + (set (match_operand:SWI48 1 "memory_operand" "") (const_int 0)) + (set (match_operand:SWI48 2 "memory_operand" "") (const_int 0)) + (set (match_operand:SWI48 3 "memory_operand" "") (const_int 0)) + (set (match_operand:SWI48 4 "memory_operand" "") (const_int 0))] + "optimize_insn_for_size_p () && peep2_regno_dead_p (0, FLAGS_REG)" + [(set (match_dup 1) (match_dup 0)) + (set (match_dup 2) (match_dup 0)) + (set (match_dup 3) (match_dup 0)) + (set (match_dup 4) (match_dup 0))] +{ + ix86_expand_clear (operands[0]); +}) + +(define_peephole2 + [(match_scratch:SWI48 0 "r") + (set (match_operand:SWI48 1 "memory_operand" "") (const_int 0)) + (set (match_operand:SWI48 2 "memory_operand" "") (const_int 0))] + "optimize_insn_for_size_p () && peep2_regno_dead_p (0, FLAGS_REG)" + [(set (match_dup 1) (match_dup 0)) + (set (match_dup 2) (match_dup 0))] +{ + ix86_expand_clear (operands[0]); +}) + +(define_peephole2 + [(match_scratch:SWI48 0 "r") + (set (match_operand:SWI48 1 "memory_operand" "") (const_int 0))] + "optimize_insn_for_size_p () && peep2_regno_dead_p (0, FLAGS_REG)" + [(set (match_dup 1) (match_dup 0))] +{ + ix86_expand_clear (operands[0]); +}) + ;; Reload dislikes loading constants directly into class_likely_spilled ;; hard registers. Try to tidy things up here. (define_peephole2 diff --git a/gcc/testsuite/gcc.target/i386/pr11877.c b/gcc/testsuite/gcc.target/i386/pr11877.c new file mode 100644 index 00000000000..5a488cccf77 --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/pr11877.c @@ -0,0 +1,16 @@ +/* PR target/11877 */ +/* { dg-do compile } */ +/* { dg-options "-Os" } */ + +void foo (long long *p) +{ + *p = 0; +} + +void bar (int *p) +{ + *p = 0; +} + +/* { dg-final { scan-assembler-times "xorl\[ \t\]" 2 } } */ +/* { dg-final { scan-assembler-not "\\\$0," } } */
reply other threads:[~2021-06-21 7:56 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20210621075638.161833886C6C@sourceware.org \ --to=sayle@gcc.gnu.org \ --cc=gcc-cvs@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: linkBe 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).