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] GCSE after reload - resubmit (SPECint +1.5% fp -0.5%).


Hi Mostafa,

I may have found a possible place where the failure occurs.

--- 930628-1.s	2004-03-14 17:19:51.127149017 -0500
+++ 930628-1.s.1	2004-03-14 17:19:47.127159693 -0500
@@ -31,8 +31,8 @@
 	sub.l	er0,er0
 	adds	#1,er0
 	mov.l	er0,@(8,er7)
+	sub.l	er3,er3
 	adds	#4,er0
-	mov.l	@(12,er7),er3
 	cmp.l	er3,er5
 	bne	.L14
 	mov.l	@(8,er7),er2

The above is a part of the diff between the results without and with
-fgcse-after-reload.  That is, gcse replaces a load from the stack,

  mov.l	@(12,er7),er3

with loading constant 0 into register er3

  sub.l	er3,er3

Looking at 930628-1.c.24.lreg, I am pretty sure this stack location
contains variable "i".

I just generated the assembly code without -fgcse-after-reload and
applied the above "patch".  Then I got abort().  Note that at label
L14, we have code to do

  if (&tp[i][ki][1 + mi] == &tp[j][kj][1])
    abort ();

If "i" is fixed to 0 (by gcse), then this comparison would fail when
j = 1.  In fact, without above "patch", I watched er3 at
"cmp.l er3,er5" above, and I saw 0 twice and 1 once.  That is, er3
shouldn't be fixed to 0.

Hope this helps,

Kazu Hirata


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