How to handle subreg(mem(X)) after reload?

James E Wilson wilson@specifixinc.com
Fri Jan 14 23:27:00 GMT 2005


On Thu, 2005-01-13 at 20:16, Robert Baruch wrote:
> 2179 is the unrecognized insn. It beats me where the W <- W move came
> in... in any case, I'm attaching the port which includes the md file
> as well as the .c and .h files. Hopefully someone will be able to spot
> the dumb thing I did to cause this problem :(

There is a problem with your move patterns.  You should only have one
for each mode.

Move patterns are special.  Reload will recognize an insn to match it to
a pattern in the md file, and then emit move insns to make the operands
match the constraints.  It will not re-recognize the insn after emitting
reloads.  Non-move insns can be fixed by emitting move insns around
them.  However, it makes no sense to emit move insns around another move
insn, so we just fix them in place, and this in turn means that having
multiple move patterns doesn't work.

So what is happening in this case is that you have multiple movqi
patterns some which accept mem and some which don't.  Reload recognizes
the pattern as movqi_nomem, emits reloads which add a mem, and then
fails because the movqi_nomem pattern does not accept memory operands. 
You need to have a single movqi_internal pattern with multiple
alternatives that accept all valid operand combinations.  Do not write
patterns that contain explicit MEM, instead use the 'm' constraint.  If
your target has non-orthognal addressing modes that make use of 'm'
difficult, then this may take a bit of work.  You might need to define
extra constraints to match certain types of (mem (address)) operands. 
But you still need to adhere to the general rule here, that a move insn
must contain alternatives that match any changes that reload might make
for the move insn.  The easiest way to meet this is to have a single
move insn for each mode.

There are of course exceptions to the general rules, but you should get
the port working first, and then worry about adding more patterns to
optimize special cases.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com




More information about the Gcc mailing list