This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Base register restrictions


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]