register move costs broken

Jeffrey A Law law@redhat.com
Tue Feb 13 22:15:00 GMT 2001


  In message < Pine.LNX.4.21.0102141611450.32094-100000@front.linuxcare.com.au >y
ou write:
  > This patch:
  > 
  > Mon Feb 12 17:28:48 CET 2001  Jan Hubicka  <jh@suse.cz>
  > 	* regclass.c (init_reg_sets_1): Optimize calculation of move_cost
  > 	arrays.
  > 
  > has dramatically changed may_move_in_cost and may_move_out_cost.  I don't
  > know whether that was intentional, but the effect on hppa64 is rather bad.
  > I'm seeing things like
  > 
  > serial.c: In function `change_speed':
  > serial.c:1803: Insn does not satisfy its constraints:
  > (insn 1409 1406 649 (set (reg:DI 60 SAR [269])
  >         (mem:DI (plus:DI (reg/f:DI 30 %r30)
  >                 (const_int -248 [0xffffff08])) 0)) 123 {*pa.md:3157} (nil)
  >     (nil))
  > serial.c:1803: confused by earlier errors, bailing out
Note there's a bug either in the PA backend or reload which is closely
related to this failure.

In particular if we have a multiply which is then used as a shift count
in a variable shift instruction, then we can end up in a situation where
we need to copy from an FP register into the SAR register.

Doing that requires the use of both secondary memory and one or more secondary
reload registers (ugh).  ie

	store fpreg into secondary memory location
	load from secondary memory location into general reg
	move general reg into SAR

The secondary memory location might be in a large stack frame and thus we may
need to reload the address for the secondary memory location.

I've been pondering this in my spare time and have been meaning to look and
see if we've got the secondary memory/reload register stuff defined properly
in the PA backend and whether or not reload will DTRT.

jeff



More information about the Gcc-bugs mailing list