double_reg_address_ok

double_reg_address_ok

[Richard Henderson]

This is truely ancient history, but why

Wed Sep  6 00:39:35 1989  Richard Stallman  (rms at sugar-bombs.ai.mit.edu)

        * reload1.c (reload): When setting double_reg_address_ok,
        require it to be offsettable.

There does not currently appear to be anything about the code that
is predicated on double_reg_address_ok that seems to require that
the result be offsettable.

The fact that we currently require this means that on Sparc, reloading
large offsets off of fp takes an extra instruction and register.


r~

Re: double_reg_address_ok

[Richard Henderson]

> There does not currently appear to be anything about the code that
> is predicated on double_reg_address_ok that seems to require that
> the result be offsettable.

Follow up: A Sparc bootstrap and check show no regressions.  FWIW.


r~

Re: double_reg_address_ok

[Jeffrey A Law]

  In message < 19980405034830.11235@dot.cygnus.com >you write:
  > This is truely ancient history, but why
  > 
  > Wed Sep  6 00:39:35 1989  Richard Stallman  (rms at sugar-bombs.ai.mit.edu)
  > 
  >         * reload1.c (reload): When setting double_reg_address_ok,
  >         require it to be offsettable.
  > 
  > There does not currently appear to be anything about the code that
  > is predicated on double_reg_address_ok that seems to require that
  > the result be offsettable.
  > 
  > The fact that we currently require this means that on Sparc, reloading
  > large offsets off of fp takes an extra instruction and register.
Well, it looks like this was a sparc related change:

        * reload1.c (reload): When setting double_reg_address_ok,
        require it to be offsettable.
        * out-sparc.c (output_fp_move_double): Now safe to use std
        for all reg+reg addresses.


I presume sparc.md at the time had a pattern which accepted any old
memory address.  One might argue it should have accepted only offsettable
addresses or that output_fp_move_double should handle a memory address
that is not offsettable.

The PA handles this case by incrementing a register in the address
before the memref, then decrementing it afterwards.

jeff

Re: double_reg_address_ok

[Jim Wilson]

	There does not currently appear to be anything about the code that
	is predicated on double_reg_address_ok that seems to require that
	the result be offsettable.

There are places in reload where it assumes that if an address has been
reloaded already, then it must be offsettable.  This avoids needing multiple
possibly conflicting reloads for the same address.  See the 'o' case in
reload.c.

See in particular the reg_equiv_address case.  If we have an address using
an unallocated pseudo, and that pseudo lives in a stack slot with such a
large offset that it can't be accessed with a REG+CONST_INT addressing mode,
and we need this address to be offsettable, then using a REG+REG addressing
mode to access it will fail.  Hence we can't allow reload to generate it.
This is just an educated guess though, so I am not sure if it is right.
And if it is right, there may be an easy way to work around it but that no
one has tried yet.

Jim