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

[Robert Baruch <autophile at gmail dot com>]

On Fri, 14 Jan 2005 13:33:55 -0800, James E Wilson
<wilson@specifixinc.com> wrote:

> 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.

Hi Jim,

Thanks for answering... I went ahead and replaced all my *movqi insns
with a single one which should accept everything:

(define_insn "*movqi"
	[(set (match_operand:QI 0 "nonimmediate_operand" "=r,w,W,W,W,m,W")
		  (match_operand:QI 1 "general_operand"         "W,W,r,i,w,W,m"))]
  "((!reload_in_progress && !reload_completed) || 
	  pic_is_w_reg(operands[0]) || pic_is_w_reg(operands[1]))"
  "* return pic_output_movqi (insn, operands);"
  [(set_attr "cc" "z")]
  )

This is absolutely identical to the original *movqi_nomem, except that
I added m <- W and W <- m (W being the register that all moves must go
through), and I changed the code generator to a function in pic.c.

However, now gcc fails even earlier, not recognizing this insn, during
regmove_optimize:

../../Desktop/gcc-3.4.3/gcc/libgcc2.c:468: error: unrecognizable insn:
(insn:HI 47 46 51 0 ../../Desktop/gcc-3.4.3/gcc/libgcc2.c:460 (set:QI
(mem:QI (reg:QI 51 FSR) [0 S1 A8])
        (reg:QI 72)) -1 (insn_list 45 (insn_list 46 (nil)))
    (expr_list:REG_DEAD (reg:QI 51 FSR)
        (expr_list:REG_EQUAL (const_int 0 [0x0])
            (nil))))

So hang on... if my *movqi insn is pretty much the union of all my
previous *movqi's, why would this insn get rejected, or why would it
get accepted when all the *movqi's were present??

Changed port attached. Can you look at this one, compared to the
previous one, and explain why this insn isn't recognized? I'm getting
pretty confused as to when and in what order define_insn,
define_expand, and the various predicates and conditions are actually
used.

Thanks,

--Rob

Attachment: pic-20050115.tgz
Description: GNU Zip compressed data