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
