This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about merging two instructions.
- From: Roger Sayle <roger at eyesopen dot com>
- To: Leehod Baruch <LEEHOD at il dot ibm dot com>
- Cc: gcc at gcc dot gnu dot org, Steven Bosscher <stevenb at suse dot de>, Paolo Bonzini <paolo dot bonzini at lu dot unisi dot ch>, Mircea Namolaru <NAMOLARU at il dot ibm dot com>
- Date: Sun, 21 Aug 2005 10:40:23 -0600 (MDT)
- Subject: Re: Question about merging two instructions.
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
--