On Sun, 21 Aug 2005, Leehod Baruch wrote:
> *** 329,334 ****
> --- 328,341 ----
> GET_MODE (SUBREG_REG (x)),
> SUBREG_BYTE (x));
> return op0 ? op0 : x;
> + }
> + if (code == SET)
> + {
> + op0 = simplify_replace_rtx (XEXP (x, 0), old_rtx, new_rtx);
> + op1 = simplify_replace_rtx (XEXP (x, 1), old_rtx, new_rtx);
> + if ((op0 == XEXP (x, 0)) && (op1 == XEXP (x, 1)))
> + return x;
> + return gen_rtx_SET (VOIDmode, op0, op1);
> }
> break;
>
> This way, when the replacement succeeds and the result instruction
> is recognizable, I can eliminate the extension.
>
> Does it seem like a good change?
> Does anyone have a better solution?
This approach seems reasonable. The current structure of the code
in simplify_replace_rtx is intended to handle RTL expressions rather
than patterns, so normally it would be passed just SET_SRC (pat),
instead of the whole set.
The reason why no-one has wanted/required simplify_replace_rtx to
work on SETs is that all current passes tend to be cautious about
changes to the LHS of an assignment. Performing substitution and
simplifications in the RHS/SET_SRC always produces a semantically
equivalent instruction, but blindly replacing subexpressions in
the LHS/SET_DEST can significantly change its meaning.
Hence, when combine/GCSE/CSE/reload and other RTL optimization
passes modify the target/destination of an assignment, they only
perform the transformations they expect or can guarantee are safe
(building the SET themselves), but are happy to let simplify_replace_rtx
do it's thing on the source expression.
To summarise, the change above is not unreasonable and I'd be
happy to allow this change to simplify-rtx.c, but I'd be more
cautious about where and why it was used. For example, if you're
sure nothing bad can happen in the LHS, it might be reasonable
to instead place this code in a simplify_replace_set() function.
As the SET (and perhaps support for PARALLEL) should only ever
occur at the top-level, which can then call the recursive
simplify_replace_rtx.
I hope this helps.
Roger
--
