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: RFC: remove find_replacement. (pr24912 / pr25335)


Bernd Schmidt wrote:
I've tested the patch below against an i686-linux, an arm-elf, a bfin-elf, and an sh-elf compiler, and did not once manage to produce different output before and after the patch. I assume my theory is correct that whatever this code does is also done by reload_cse. Unless someone finds a testcase that has a regression or has another valid reason for an objection, I'll install this in a day or two.

The tests I mentioned above involved compiling every file in gcc from .i to .s. Joern suggested I also try Toshi's stress test suite; I had an older version of it lying around and used this as well as all files from Crafty and my own UAE against an sh-elf and an s390-linux compiler. I managed to produce only two differences in output; in one file a store instruction moved by a couple of instructions, in another file (Crafty's book.i) there was one genuine case of a missed CSE opportunity. We have


r1 = 99;
[stuff, involving a use of r1]
r0 = 99;
fpul = r0;

which I'm certain could be fixed by making reload_cse a bit more clever.

But I don't think one instance of a minor lost optimization across a test of several platforms is enough to defend keeping this code in, especially since it's making further simplification more difficult than necessary.

	* reload1.c (emit_input_reload_insns): Delete code that tries to
	inherit using find_equiv_reg.

Hence, I bootstrapped and regression tested this on i686-linux, and committed it.


Ulrich, can you retry Joern's original patch on your machine?


Bernd



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