This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Don't expand MEM1 op= MEM2 as temp = MEM1; temp op= MEM2; MEM1 = temp just because we couldn't add REG_EQUIV note (PR rtl-optimization/56151)
- From: Jeff Law <law at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 11 Feb 2013 13:18:27 -0700
- Subject: Re: [PATCH] Don't expand MEM1 op= MEM2 as temp = MEM1; temp op= MEM2; MEM1 = temp just because we couldn't add REG_EQUIV note (PR rtl-optimization/56151)
- References: <20130211194902.GB4385@tucnak.redhat.com>
On 02/11/13 12:49, Jakub Jelinek wrote:
Hi!Note that expanding as MEM op= X puts the decision about whether or not
to use a temporary entirely into the backend, where it can be split via
a define_insn_and_split. I'm generally OK with that.
As discussed in this PR, MEM1 op= MEM2 is usually better expanded
as temp = MEM2; MEM1 op= temp; if target supports that, even when it
means we can't add a REG_EQUIV note in that case (it would be
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
2013-02-11 Jakub Jelinek <firstname.lastname@example.org>
Steven Bosscher <email@example.com>
* optabs.c (add_equal_note): Don't return 0 if target is a MEM,
equal to op0 or op1, and last_insn pattern is CODE operation
with MEM dest and one of the operands matches that MEM.
* gcc.target/i386/pr56151.c: New test.
However, it is worth noting this can inhibit CSE if the MEM was already
available in a pseudo. I don't think this is serious enough to warrant
rejecting this change. If it turns out to be a problem we'll need to do
I'd suggest adding a comment here about the details of 56151 rather than
referencing the BZ database. Ideally we want a developer to be able to
read the code and understand why it works the way it does. Now the
developer has to go find the bug in the database and read that too.
+ /* For MEM target, with MEM = MEM op X, prefer no REG_EQUAL note
+ over expanding it as temp = MEM op X, MEM = temp. See PR56151. */
I'd also suggest a quick note that this style of code generation can
inhibit CSE in some cases.
With those two comment changes, approved.