Another movdf_hardfloat32 patch

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> In message < 199906221520.LAA47518@kitch12.watson.ibm.com >you write:
>> No, I disagree with this solution.  We need to change the test to
>> recognize LO_SUM as well as offsettable addresses, not kludge the
>> non_offsettable path.

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.  rs6000.c:print_operand_address() and rs6000.c:print_operand() case
'L' already handle th LO_SUM addresses.  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.

	If LO_SUM was not handled properly in my version of the recent
change, then

	      if (offsettable_memref_p (operands[1])) ...

needs to be changed to accept BOTH offsettable memory references and
LO_SUM references.  In other words, something like:

	      if (offsettable_memref_p (operands[1])
	          || GET_CODE (operands[1]) == LO_SUM) ...

	If this is not a simple test because we need to recursively look
inside operands, then we need to write an additional rs6000-specific
constraint pattern that tests both offsettable and LO_SUM that should be
used in place of the current tests in movdf_hardfloat32 .

	I would greatly appreciate if you would help me correct this
pattern. 

David