This is the mail archive of the
mailing list for the GCC project.
Re: ppc patch
- To: law at cygnus dot com
- Subject: Re: ppc patch
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Sat, 22 Aug 1998 14:37:28 -0400
- Cc: meissner at cygnus dot com, egcs-patches at cygnus dot com
>>>>> 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
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.