From: Uros Bizjak <ubizjak@gmail.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Jeff Law <law@redhat.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Optimize away x86 mem stores of what the mem contains already (PR rtl-optimization/79593)
Date: Tue, 08 Jan 2019 07:29:00 -0000 [thread overview]
Message-ID: <CAFULd4Y6VLQd7aazXp8fGvAixWjkk=XRSpNE0=kCjwTywHRNNw@mail.gmail.com> (raw)
In-Reply-To: <20190107225116.GU30353@tucnak>
On Mon, Jan 7, 2019 at 11:51 PM Jakub Jelinek <jakub@redhat.com> wrote:
>
> Hi!
>
> As mentioned in that PR, we have a SI->DImode zero extension and RA happens
> to choose to zero extend from a SImode memory slot which is the low part of
> the DImode memory slot into which the zero extension is to be stored.
> Unfortunately, the RTL DSE part really doesn't have infrastructure to
> remember and, if needed, invalidate loads, it just remembers stores, so
> handling this generically is quite unlikely at least for GCC9.
>
> This patch just handles that through a peephole2 (other option would be to
> handle it in the define_split for the zero extension, but the peephole2 is
> likely to catch more things).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Is there a reason stack registers are excluded? Before stackreg pass,
these registers are just like other hard registers.
Other that that, there is no need for REG_P predicate; after reload we
don't have subregs and register_operand will match only hard regs.
Also, please put peep2_reg_dead_p predicate in the pattern predicate.
Uros.
> 2019-01-07 Jakub Jelinek <jakub@redhat.com>
>
> PR rtl-optimization/79593
> * config/i386/i386.md (reg = mem; mem = reg): New define_peephole2.
>
> --- gcc/config/i386/i386.md.jj 2019-01-01 12:37:31.564738571 +0100
> +++ gcc/config/i386/i386.md 2019-01-07 17:11:21.056392168 +0100
> @@ -18740,6 +18740,21 @@ (define_peephole2
> const0_rtx);
> })
>
> +;; Attempt to optimize away memory stores of values the memory already
> +;; has. See PR79593.
> +(define_peephole2
> + [(set (match_operand 0 "register_operand")
> + (match_operand 1 "memory_operand"))
> + (set (match_dup 1) (match_dup 0))]
> + "REG_P (operands[0])
> + && !STACK_REGNO_P (operands[0])
> + && !MEM_VOLATILE_P (operands[1])"
> + [(set (match_dup 0) (match_dup 1))]
> +{
> + if (peep2_reg_dead_p (1, operands[0]))
> + DONE;
> +})
> +
> ;; Attempt to always use XOR for zeroing registers (including FP modes).
> (define_peephole2
> [(set (match_operand 0 "general_reg_operand")
>
> Jakub
next prev parent reply other threads:[~2019-01-08 7:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-07 22:51 Jakub Jelinek
2019-01-08 7:29 ` Uros Bizjak [this message]
2019-01-08 9:27 ` Jakub Jelinek
2019-01-08 10:49 ` Uros Bizjak
2019-01-08 11:43 ` Jakub Jelinek
2019-01-08 17:40 ` Uros Bizjak
2019-01-11 19:03 ` Jeff Law
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='CAFULd4Y6VLQd7aazXp8fGvAixWjkk=XRSpNE0=kCjwTywHRNNw@mail.gmail.com' \
--to=ubizjak@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=law@redhat.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).