This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Base register restrictions
- From: Jeff Law <law at redhat dot com>
- To: Jim Wilson <wilson at codesourcery dot com>
- Cc: Dobes <bdobry at udel dot edu>, gcc at gcc dot gnu dot org
- Date: Tue, 30 Jun 2009 20:04:54 -0600
- Subject: Re: Base register restrictions
- References: <24259346.post@talk.nabble.com> <4A497766.6040909@codesourcery.com>
Jim Wilson wrote:
Dobes wrote:
I am working on a port to an architecture with some strict rules. The
restriction that I am unable to figure out how to enforce is a base
register
that is allowed in the destination operand, but not in a source operand.
GCC does not provide any way in the old GO_IF_LEGITIMATE_ADDRESS (or
the new TARGET_LEGITIMATE_ADDRESS_P) to distinguish between an address
used in a dest and an address used in a source.
Right.
You probably just have to limit this to addresses that are valid in
both places. You can then add extra constraints to try to recognize
other types of memory addresses.
Precisely.
So you could use "mR" for destination operands and "mS" for source
operands, where R and S are extra constraints that have been defined
appropriately. An example to look at might be the s390 port. The
movti pattern for instance uses QRST, where only Q and S can be in the
dest, but any of Q, R, S, or T can be in the source. And it doesn't
seem to use 'm' much.
The PA port may also provide good examples for how to deal with this
problem. In a nutshell, the PA port has indexed loads, but no indexed
stores (when using general purpose registers as the source operand).
Of course, it would be nice if gcc handled this better, but fixing
this is probably a lot of work.
Yes, it would be nice, but I think it'd be a huge amount of work -- I
looked into it 10+ years ago and gave up. I don't think significant
changes have been made to the fundamental addressing mode assumptions
since that time.
Jim