Re: Another movdf_hardfloat32 patch

[Jeffrey A Law <law at cygnus dot com>]

  In message <9906222159.AA46914@marc.watson.ibm.com>you write:
  > >>>>> Jeffrey A Law writes:
  > Jeff> No.    A LO_SUM is *NOT* an offsettable address, at least that is the
  > Jeff> case on most targets.  This was discussed at length in a thread a few
  > Jeff> months ago.
  > 
  > 	You seem to have misunderstood my objection.  The LO_SUM case
  > should not use the non-offsettable version of the output that I recently
  > added. 
Why?  I'll repeat a LO_SUM address is not offsettable, so it should be
using the non-offsettable version of the output routine.  I think this is
the core point of contention.

  >  rs6000.c:print_operand_address() and rs6000.c:print_operand() case
  > 'L' already handle th LO_SUM addresses.
But I would claim this can't work.

I'd be very interested in hearing why you think a LO_SUM address can be
handled like an offsettable address.

Consider the case where the low 16bits of the symbolic part of the address
are 0xfffc.  When you add 4 to get the high word you end up wrapping around
and lose.

Maybe the PPC is doing something weird which makes this work.  If so, can you
please explain how it works?


  > All of this, including LO_SUM,
  > was working before I made the change to fix the indexed address case.
  > There is no need to adjust a register to handle the LO_SUM case.
While I may have been "working" in the sense that it was not triggering
errors, I fail to see how it can handle the case noted above.  And this
is precisely why a LO_SUM has to be treated as a non-offsettable address.

jeff