ppc patch

[David Edelsohn]

>>>>> Jeffrey A Law writes:

Jeff> Note that we have 'o' for an offsettable memory address.  However,
Jeff> autoincrement memory addresses are not offsettable.

Jeff> Luckily I believe the fix is simple.  All I think we need to do is
Jeff> change 'o' above to 'm' in both occurrences.  This should be safe
Jeff> unless there is some reason why we need to be avoiding autoinc addresses
Jeff> for DFmode memory accesses when TARGET_SOFT_FLOAT is enabled.

Jeff> Further evidence that this is the right fix can be found in the movdi
Jeff> insn, which uses 'm' and generates _identical_ code for the two alternatives
Jeff> we care about.

	The movdf matcher patterns include a lot of comments about
auto-increment becausethe *load* the target register might be the source
address register as well.  The failure in question seems to be a *store*
to memory which cannot have this problem so I do not understand why the
constraint needs to be 'o' for the *store*.

	The movdi matcher patterns were written by a different person who
might not have realized the significance / necessity of the 'o' for the
load case when operating in 32-bit mode.  I don't think that you should
infer anything from the presence or absence of the constraint on the movdi
pattern. 

	I do not understand what "change the 'o' above to 'm' in BOTH
OCCURENCES" means.  Changing it for the store to memory seems safe, but
changing it for the load to a pair of GPRs may not be safe.  I question
whether movdi_32 should be 'o' for load and 'm' for store as well.

	I would agree with changing the movdf_softfloat32 memory store
from constraint 'o' to constraint 'm', but changing the load constraint
might have other side-effects.

David