Jan Hubicka <[email protected]> writes: >> >> I can accept the issue as a matter of documentation, but I don't >> understand the rest. Remember that all the patterns are executed in >> parallel. I don't see how adding a USE in parallel could affect >> anything about how the operand is used. > >> >> >> (define_insn "*rep_movqi" >> >> >> [(set (match_operand:P 2 "register_operand" "=c") (const_int 0)) >> >> >> (set (match_operand:P 0 "register_operand" "=D") >> >> >> (plus:P (match_operand:P 3 "register_operand" "0") >> >> >> (match_operand:P 5 "register_operand" "2"))) >> >> >> (set (match_operand:P 1 "register_operand" "=S") >> >> >> (plus:P (match_operand:P 4 "register_operand" "1") (match_dup >> >> >> 5))) >> >> >> (set (mem:BLK (match_dup 3)) >> >> >> (mem:BLK (match_dup 4))) >> >> >> (use (match_dup 5))] > > Without the extra use the patterns says that the only use of operand 5 (CX) is > to add it to DX and SX. > > So seeing something like > > memcpy(DX,SX,10) > DX+=10 > SX+=10 > > is IMO foldable to > > memcpy(DX,SX,20) > > Not that current forwprop/combine would do that. But in theory I think it is > valid > transform.
No, it's not. All the SETs are done in parallel--the define_insn has an implicit PARALLEL wrapped around the insns. You're trying to pull some of the outputs into the inputs, but that is not permitted by the rules of RTL. Ian
