This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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)


On 02/11/13 12:49, Jakub Jelinek wrote:
Hi!

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
self-referential).

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
for trunk?

2013-02-11  Jakub Jelinek  <jakub@redhat.com>
	    Steven Bosscher   <steven@gcc.gnu.org>

	PR rtl-optimization/56151
	* 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.
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.

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 more tuning.

+	{
+	  /* 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 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.

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.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]