@@ -1,3 +1,7 @@
+2015-12-13 Kazu Kirata <kazu@gcc.gnu.org>
+
+ * config/m68k/m68k.md (load feeding clear byte): New peephole2.
+
2015-12-13 Tom de Vries <tom@codesourcery.com>
* tree-ssa-structalias.c (find_func_clobbers): Handle sizes and kinds
@@ -7601,3 +7601,36 @@
(include "cf.md")
(include "sync.md")
+
+;; Convert
+;;
+;; move.l 4(%a0),%a0
+;; clr.b (%a0,%a1.l)
+;;
+;; into
+;;
+;; add.l 4(%a0),%a1
+;; clr.b (%a1)
+;;
+;; The latter is smaller. It is faster on all models except m68060.
+
+(define_peephole2
+ [(set (match_operand:SI 0 "register_operand" "")
+ (mem:SI (plus:SI (match_operand:SI 1 "register_operand" "")
+ (match_operand:SI 2 "const_int_operand" ""))))
+ (set (mem:QI (plus:SI (match_operand:SI 3 "register_operand" "")
+ (match_operand:SI 4 "register_operand" "")))
+ (const_int 0))]
+ "(optimize_size || !TUNE_68060)
+ && (operands[0] == operands[3] || operands[0] == operands[4])
+ && ADDRESS_REG_P (operands[1])
+ && ADDRESS_REG_P ((operands[0] == operands[3]) ? operands[4] : operands[3])
+ && peep2_reg_dead_p (2, operands[3])
+ && peep2_reg_dead_p (2, operands[4])"
+ [(set (match_dup 5)
+ (plus:SI (match_dup 5)
+ (mem:SI (plus:SI (match_dup 1)
+ (match_dup 2)))))
+ (set (mem:QI (match_dup 5))
+ (const_int 0))]
+ "operands[5] = (operands[0] == operands[3]) ? operands[4] : operands[3];")
@@ -1,5 +1,7 @@
2015-12-13 Jeff Law <law@redhat.com>
+ * gcc.target/m68k/pr19201.c: New test.
+
* gcc.target/m68k/pr63347.c: Remove #include <stdlib> add -w to
command line options.
* gcc.target/m68k/20090709-1.c: Adjust expected output.
new file mode 100644
@@ -0,0 +1,13 @@
+/* { dg-options "-w -O2 -fomit-frame-pointer" } */
+/* { dg-final { scan-assembler-not "%a.,%\[ad\]..l" } } */
+
+struct X {
+ char *a;
+ /* other members */
+ int b;
+};
+
+void f (struct X *x)
+{
+ x->a[x->b] = 0;
+}
Every release I try to dig through some old bug reports and clear them out of the system. This release is no different. I'm a bit surprised I didn't tackle bz19201 in prior releases given that Kazu had an almost correct patch attached to the BZ. I suspect this could be generalized to more than just clearing bytes. But I doubt it's worth any real effort as this is ultimately m68k specific. Essentially Kazu's patch rewrites a load+store sequence where the load feeds the store's address computation. He was missing a check to verify the that the target of the load was an address register. That in turn causes failures such as reported by Mikael Pettersson in c#15 when he tried including the patch in his builds. I was able to trigger the same kind of failure as Mikael using Kazu's patch and was able to confirm that adding the ADDRESS_REG_P check avoids those problems. I've got a bootstrap running, but it'll be, umm, a long time before it finishes (both for the control build and the build with the updated patch). The control build is into stage2 while the build with the patch is still building libraries for stage1. But it's well past the point where it failed with the incorrect initial patch. Installed on the trunk. jeff commit 42582e91448c6afcc162d95229e14aac23a950ed Author: Jeff Law <law@redhat.com> Date: Sun Dec 13 06:05:03 2015 -0700 [PATCH][PR target/19201] Peephole to improve clearing items in structure for m68k * config/m68k/m68k.md (load feeding clear byte): New peephole2. * gcc.target/m68k/pr19201.c: New test.