Re: Question about merging two instructions.

[Roger Sayle <roger@eyesopen.com>]

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
--