Jan Hubicka <hubi...@ucw.cz> writes: >> Jan Hubicka <hubi...@ucw.cz> 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. > > In expanded form it is > > (set (reg5) (const 10)) > > (parallel [(set (reg2) (const 0)) > (set (reg0) (plus (reg3) (reg5))) > (set (reg1) (plus (reg4) (reg5))) > (set (mem (reg3)) (mem (reg4)))]) > > (set (reg0) (plus (reg0) (const 10))) > > (set (reg1) (plus (reg1) (const 10))) > > instructions separated by empty lines. > > transformed into: > (set (reg5) (const 20)) > > (parallel [(set (reg2) (const 0)) > (set (reg0) (plus (reg3) (reg5))) > (set (reg1) (plus (reg4) (reg5))) > (set (mem (reg3)) (mem (reg4)))]) > > I do not see puling inputs to outputs here.
Ah, thanks. I finally see what you are getting at. Perhaps you are right. I'm not sure. Ian