On Sun, 21 Aug 2005, Leehod Baruch wrote: > >>(insn 1 0 2 0 (set (reg/v:Xmode r) > >> (sign_extend:Xmode (op:Ymode (...)))) > >>(insn 2 1 3 0 (set (lhs) (rhs))) > > 1. Can you please give me an example of something bad that can happen to > the LHS. Maybe I'm missing something here.
(set (reg:Xmode r) (sign_extend:Xmode (reg:Ymode p))) (set (subreg:Ymode (reg:Xmode r) 0) (reg:Ymode q)) would be transfomed (by replacing all uses of "reg r" with it's definition on both LHS and RHS) into: (set (reg:Ymode p) (reg:Ymode q)) Originally, r's high part would be set to the signbit of p and r's low part would be set to the value of q. After the transformation, we now overwrite the operand p with the value q, which isn't quite the same thing. > 2. After calling simplify_replace_rtx I try to recognize the instruction. > Is this been cautious or is it unnecessary? Except for register-register moves, all synthesized instructions need to be rerecognized, especially after "RTL simplification". > 3. Isn't it reasonable to expect that every instance on old_rtx will be > replaced by new_rtx even if it can't be simplified? > This is what I understand from the function's documentation. > But actually every expressions that can't be simplified is not replaced. Every instance of old_rtx should be replaced by new_rtx. You may be getting confused by the code to reduce memory usage. If a replacement doesn't occur within all operands/subtrees of a tree, then return this tree. The invariant in the recursion is that if a substitution has been made anywhere in the tree, it returns a newly allocated RTX. Simplification of this newly allocated RTX, will itself return a newly allocated RTX. Hence the testing whether the return value of simplify_replace_rtx matches it's original first argument is a way of determining whether any substitution has been made (whether it was subsequently simplified or not). The one caveat to this is that simplify_replace_rtx is less robust to unrecognized RTL codes than replace_rtx. i.e. it won't traverse UNSPECs or other non-unary/non-binary/non-comparison expressions. This can/should probably be fixed by tweaking the "default:" case to match the GET_RTX_FORMAT loop in replace_rtx. Note this isn't a simple cut'n'paste, as replace_rtx destructively overwrites it's input expression, whilst simplify_replace_rtx returns a different tree if anything changed. Roger --