RFC: offsettable problem

[Dale Johannesen]

This shows up on rs6000, but I think the rot goes deeper than that....
The rs6000 BE currently generates invalid assembly for this:

(insn:TI 478 481 482 isosurface.fppized.f90:1539 (set (mem:DF (plus:SI 
(reg/f:SI 1 r1)
                 (const_int 32760 [0x7ff8])) [0 S8 A8])
         (reg:DF 9 r9 [579])) 316 {*movdf_hardfloat32} (insn_list 4391 
(insn_list 4390 (nil))))

This ought to be OK, it can generate
      lwz r9, 32760(r1)
      lwz  r10, 32764(r1)
with all the offsets in range.  (Presumably some earlier phase thought 
so too.)
However, the movdf_hardfloat32 pattern calls
   offsettable_address_p(1, DFmode,  R1+32760)
which calls
   mode_dependent_address_p(R1+32760)
which calls
   GO_IF_MODE_DEPENDENT_ADDRESS
which gets back into the rs6000 code, which requires enough space for 
TFmode, which
is not there in this edge case.   It doesn't have a mode to work with 
at that point, and is
actually rather more lenient than the description of 
GO_IF_MODE_DEPENDENT_ADDRESS
says it ought to be (more on this below).

So I guess I can fix this by cloning offsettable_address_p in the 
rs6000 BE and making it
do the right thing.  (I'm not really interested in solutions that 
accept the pattern above as
non-offsettable; the code you get that way is terrible, and it's Just 
Wrong.)
But it looks to me like offsettable_address_p is wrong.  It says

/* Return 1 if Y is a memory address which contains no side effects
    and would remain valid after the addition of a positive integer
    less than the size of that mode.

But that's not what it does.  It calls mode_dependent_address, which 
does not take
a mode, and is supposed to do this:

/* Return 1 if ADDR is an address-expression whose effect depends
    on the mode of the memory reference it is used in.

And that calls GO_IF_MODE_DEPENDENT, which implements this, and that's
consistent with its documentation.  But that's too restrictive for what 
offsettable_address_p
wants to do.*

But this is low-level and has been around a while, so there's no way I 
can change it
here without breaking things, right?   Whoever put this rather 
frustrated comment in
the rs6000 code seemed to think so:

/* Go to LABEL if ADDR (a legitimate address expression)
    has an effect that depends on the machine mode it is used for.
    On the RS/6000 this is true of all integral offsets (since AltiVec
    modes don't allow them) or is a pre-increment or decrement.
    ??? Except that due to conceptual problems in offsettable_address_p
    we can't really report the problems of integral offsets.  So leave
    this assuming that the adjustable offset must be valid for the
    sub-words of a TFmode operand, which is what we had before.  */

So do we actually know what will break?  Suggestions?