On Fri, May 10, 2013 at 11:51 PM, Mike Stump wrote:
> I have a instruction pattern for my port that reads in part:
>
> [(parallel [(set (subreg:DI (match_operand:TI 0 "register_operand" "=r") 0)
> (mem:DI (plus:DI (match_operand:DI 1 "register_operand"
> "r")
> (match_operand:DI 2 "const_int_operand"
> ""))))
> (set (subreg:DI (match_dup 0) 8)
> (mem:DI (plus:DI (match_dup 1)
> (match_operand:DI 3
> "const_int_operand"))))])]
>
> The subreg seems to give web.c fits. web is looking for the match_dup and
> failing to find it, due to the fact that DF_REF_LOC is of the form (subreg:DI
> (reg:TI 5) 8), not (reg:TI 5). If I add a case for SUBREG like in the below,
> we can then find and process the subreg.
>
> So, the question is, is the port completely wrong for trying to use subreg in
> this fashion? If not, is processing subregs in this way the right way? If
> yes, Ok?
I don't think this port is completely wrong. I've looked at some other
ports and there are comparable patterns, e.g. in m68k:
;; We need a separate DEFINE_EXPAND for u?mulsidi3 to be able to use the
;; proper matching constraint. This is because the matching is between
;; the high-numbered word of the DImode operand[0] and operand[1].
(define_expand "umulsidi3"
[(parallel
[(set (subreg:SI (match_operand:DI 0 "register_operand" "") 4)
(mult:SI (match_operand:SI 1 "register_operand" "")
(match_operand:SI 2 "register_operand" "")))
(set (subreg:SI (match_dup 0) 0)
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (match_dup 1))
(zero_extend:DI (match_dup 2)))
(const_int 32))))])]
"TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE"
"")
Your web.c patch looks correct to me, but I can't approve it.
Ciao!
Steven
