Question about peephole2 and addressing mode

[Mohamed Shafi <shafitvm at gmail dot com>]

Hello all,

I am doing a port for a 32bit a target in GCC 4.4.0. The target
supports (base + offset) addressing mode for QImode store instructions
but not for QImode load instructions. GCC doesn't take the middle
path. It either supports an addressing mode completely and doesn't
support at all. I tried lot of hacks to support  (base + offset)
addressing mode only for QI mode store instructions. After a lot of
fight i finally gave up and removed the QImode support for this
addressing mode completely in GO_IF_ LEGITIMATE_ADDRESS macro. Now i
am pursing an alternate solution. Have peephole2 patterns to implement
QImode (base+offset) addressing mode for store instructions. How does
it sound?

So now i have written a peephole2 pattern like:

(define_peephole2
 [(parallel
   [(set (match_operand:SI 0 "register_operand" "")
         (plus:SI (match_operand:SI 1 "register_operand" "")
                  (match_operand:SI 2 "const_int_operand" "")))
    (clobber (reg:CCC CC_REGNUM))
    (clobber (reg:CCO EMR_REGNUM))])
  (set (mem:QI (match_dup 0))
       (match_operand:QI 3 "register_operand" ""))]
 "REGNO_OK_FOR_BASE_P (REGNO (operands[1]))
  && constraint_satisfied_p (operands[2], CONSTRAINT_N)"
 [(set (mem:QI (plus:SI (match_dup 1) (match_dup 2)))
       (match_dup 3))]
 "")


In the rtl dumps just before peephole2 pass i get

(insn 213 211 215 39 20010408-1.c:71 (parallel [
            (set (reg/f:SI 16 r0 [121])
                (plus:SI (reg/v/f:SI 18 r2 [orig:93 p ] [93])
                    (const_int -1 [0xffffffff])))
            (clobber (reg:CCC 50 sr))
            (clobber (reg:CCO 54 emr))
        ]) 18 {addsi3} (expr_list:REG_UNUSED (reg:CCO 54 emr)
        (expr_list:REG_UNUSED (reg:CCC 50 sr)
            (nil))))

(insn 215 213 214 39 20010408-1.c:71 (set (mem/f/c/i:SI (plus:SI
(reg/f:SI 23 r7)
                (const_int -32 [0xffffffe0])) [5 s+0 S4 A32])
        (reg/v/f:SI 18 r2 [orig:93 p ] [93])) 2 {*movsi_internal}
(expr_list:REG_DEAD (reg/v/f:SI 18 r2 [orig:93 p ] [93])
        (nil)))

(insn 214 215 284 39 20010408-1.c:71 (set (mem:QI (reg/f:SI 16 r0
[121]) [0 S1 A8])
        (reg/v:QI 6 d6 [orig:92 ch ] [92])) 0 {*movqi_internal}
(expr_list:REG_DEAD (reg/f:SI 16 r0 [121])
        (expr_list:REG_DEAD (reg/v:QI 6 d6 [orig:92 ch ] [92])
            (nil))))


This is not match by the peephole2 pattern. After debugging i see that
the function 'peephole2_insns' matches only consecutive patterns. Is
that true? Is there a way to over come this?

Another issue. In another instance peephole2 matched but the generated
pattern did not get recognized because GO_IF_ LEGITIMATE_ADDRESS was
rejecting the addressing mode. Since peephole2 pass was run after
reload i changed GO_IF_ LEGITIMATE_ADDRESS macro to allow the
addressing mode after reload is completed. So now the check is
something like this:

 case PLUS:
        {
          rtx offset = XEXP (x, 1);
          rtx base = XEXP (x, 0);

          if ( !(BASE_REG_RTX_P (base, strict) || STACK_REG_RTX_P (base)))
            return 0;

          /* For QImode the target does not suppport (base + offset) address
             in the load instructions. So we disable this addressing
mode till reload is completed. */
          if (!reload_completed && mode == QImode && BASE_REG_RTX_P
(base, strict))
            return 0;

I haven't run the testsuite, but Is this ok to have like this?
Please let me know your thoughts on this.

Thanks for your time.

Regards
Shafi