More on the reload problem

Bernd Schmidt crux@pool.informatik.rwth-aachen.de
Mon Nov 2 13:55:00 GMT 1998


> 
> Remember this issue:
[question whether reload inheritance will break with local spill code]

> 
> I think I know where it breaks :-)
> 
> Going back to last night's example.  We've got the following insns as we
> exit from emit_reload_insns for insn 170.

I've looked at the test case, and I don't think the problem is related to
the local spill patches (since none of the involved pseudos have hard
registers).


> (insn 531 167 512 (set (reg:SI 5 %edi)
>         (reg:SI 108)) -1 (nil)
>     (nil))
> 
> (insn 512 531 537 (set (reg:SI 1 %edx)
>         (reg:SI 5 %edi)) 54 {movsi+2} (nil)
>     (nil))
> 
> (insn 537 512 170 (set (reg:SI 0 %eax)
>         (reg:SI 60)) -1 (nil)
>     (nil))
> 
> (insn 170 537 534 (parallel[ 
>             (set (reg/v:SI 29)
>                 (unspec:SI[ 
>                         (mem:BLK (reg/v:SI 29) 0)
>                         (const_int 4)
>                         (reg:SI 60)
>                     ]  0))
>             (clobber (reg:SI 60))
>         ] ) 390 {strlensi_unroll5} (nil)
>     (nil))
> 
> (insn 534 170 172 (set (reg/v:SI 29)
>         (reg:SI 1 %edx)) -1 (nil)
>     (nil))
> 
> (insn 172 534 177 (set (reg/v:SI 29)
>         (minus:SI (reg/v:SI 29)
>             (reg:SI 108))) 157 {subsi3+1} (insn_list 170 (nil))
> 
> 
> First, note that spill_reg_store[%edi] points to insn 512 and
> spill_reg_stored_to[%edi] is (reg:SI 29).  This makes sense if you happen
> to know that insn 512 originally stored into reg29 :-)  Refer to last night's
> message.

Note that insn 512 looks differently before emit_reload_insns is called for
insn 170; during that function, it gets rewritten into the above form.
Before that, it stores pseudo 29 from spill reg edi, and the value in
spill_reg_stored_to makes perfect sense.
The insn gets rewritten by the piece of code that starts with the
following comment:

 /* If we are reloading a pseudo-register that was set by the previous
    insn, see if we can get rid of that pseudo-register entirely
    by redirecting the previous insn into our reload register.  */

As a consequence of that code, spill_reg_stored_to is no longer valid.
Later, the code to delete previous output reloads gets completely confused
for reload 1 (pseudo 108) of insn 172; this reload inherits edi from
insn 531, but spill_reg_store is still set to insn 512, which will get
deleted.
I think that the code that rewrites the output of insn 512 must ensure
that spill_reg_store gets cleared for the source of the set.  The patch
below appears to fix the problem for me, but I'm not entirely sure yet it's
really the correct solution.

Bernd

	* reload1.c (emit_reload_insns):  When rewriting the SET_DEST of a
	previous insn to store directly into our reload register, make sure
	that if the source of the previous insn is a reload register, its
	spill_reg_store and spill_reg_stored_to values are cleared.

Index: reload1.c
===================================================================
RCS file: /usr/local/cvs/gcs/gcc/reload1.c,v
retrieving revision 1.1.1.53
diff -u -p -r1.1.1.53 reload1.c
--- reload1.c	1998/10/30 13:50:41	1.1.1.53
+++ reload1.c	1998/11/02 11:03:01
@@ -6727,6 +6727,18 @@ emit_reload_insns (chain)
 		{
 		  /* Store into the reload register instead of the pseudo.  */
 		  SET_DEST (PATTERN (temp)) = reloadreg;
+
+		  /* If the previous insn is an output reload, the source is
+		     a reload register, and its spill_reg_store entry will
+		     contain the previous destination.  This is now
+		     invalid.  */
+		  if (GET_CODE (SET_SRC (PATTERN (temp))) == REG
+		      && REGNO (SET_SRC (PATTERN (temp))) < FIRST_PSEUDO_REGISTER)
+		    {
+		      spill_reg_store[REGNO (SET_SRC (PATTERN (temp)))] = 0;
+		      spill_reg_stored_to[REGNO (SET_SRC (PATTERN (temp)))] = 0;
+		    }
+
 		  /* If these are the only uses of the pseudo reg,
 		     pretend for GDB it lives in the reload reg we used.  */
 		  if (REG_N_DEATHS (REGNO (old)) == 1





More information about the Gcc-bugs mailing list