"Paulo J. Matos" <pa...@matos-sorge.com> writes:
> Expand generates:
>
> (define_insn_and_split "movmem_long"
> [(set (match_operand:QI 2 "register_operand" "d,c") (const_int 0))
> (set (mem:BLK (match_operand:QI 0 "register_operand" "d,c"))
> (mem:BLK (match_operand:QI 1 "register_operand" "x,c")))
> (set (match_dup 0) (plus:QI (match_dup 0) (match_dup 2)))
> (set (match_dup 1) (plus:QI (match_dup 1) (match_dup 2)))
> (clobber (match_scratch:QI 3 "w,w"))]
> "!TARGET_NO_BLOCK_COPY"
> "#"
> "&& reload_completed"
> [(const_int 0)]
> {
> if((which_alternative == 0 && REGNO(operands[2]) == RAH))
> || which_alternative == 1)
> {
> emit_move_insn(operands[3], operands[0]);
> emit_move_insn(operands[0], operands[2]);
> emit_move_insn(operands[2], operands[3]);
> }
> emit_insn(gen_bc2());
> DONE;
> })
>
> From what I understand + is for input/output operands, = for output
> only operands. Since in the above rule (a parallel) all operands are
> written to and read to, does this mean all their constraints should
> start with +? Or this only applies per set within each parallel (which
> doesn't seem to make much sense)?
I agree that there is something wrong here. I agree that as written
the constraints for operands 0, 1, and 2 should have a '+'.
That said, a '+' constraint is most useful for a pattern that expands
into multiple instructions. I think this would be better written along
the lines of
(set (match_operand:QI 2 "register_operand" "=d,c") (const_int 0))
(set (mem:BLK (match_operand:QI 3 "register_operand" "0")
(match_operand:QI 4 "register_operand" "1")))
(set (match_operand:QI 0 "register_operand" "=d,c")
(plus:QI (match_dup 3)
(match_operand:QI 5 "register_operand" "2"))))
(set (match_operand:QI 1 "register_operand" "=x,c")
(plus:QI (match_dup 4) (match_dup 5)))
(clobber (match_scratch:QI 3 "=w,w"))
Also it looks like it might be possible to add a third alternative such
that that alternative does not require the match_scratch.
Ian
