On Mon, Aug 22, 2005 at 03:37:27PM +0200, Paolo Bonzini wrote:
> It may still make sense changing the default case of
> simplify_replace_rtx to invoke replace_rtx rather than returning x. But
> this is unrelated, because nobody is currently passing a SET to
> simplify_replace_rtx (only expressi
Note that I don't want to replace any *def* and uses may appear in the
LHS.
Ok, I see. But you have to cope with *def*s appearing in the LHS: you
don't want to replace them, yet your modified simplify_replace_rtx will!
My plan was to use: replace_regs () to replace every use of (reg r)
w
Paolo Bonzini <[EMAIL PROTECTED]> wrote on 22/08/2005 10:10:40:
> > > I tried to use simplify_replace_rtx to replace any use of (reg r)
with[in]
> > > the right-hand-side of the extension and simplify the result.
>
> If he want to replace uses within the RHS of the extension, he should
> pass SE
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
Do I always need to recognize the result?
validate_change and apply_change_group will take care of that.
If the answer is yes, than I suppose that if something bad happens,
the recognition will fail.
No, the problem is when recognition passes, and you have a SUBREG on the
LHS that will
> > 1. Can you please give me an example of something bad that can happen
to
> > the LHS. Maybe I'm missing something here.
>
> In this case nothing, but if NEW were a subreg, it can change a lot.
Why?
Do I always need to recognize the result?
If the answer is yes, than I suppose that if som
1. Can you please give me an example of something bad that can happen to
the LHS. Maybe I'm missing something here.
In this case nothing, but if NEW were a subreg, it can change a lot.
3. Isn't it reasonable to expect that every instance on old_rtx will be
replaced by new_rtx even if it can
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.
Which is why, OTOH, I would be *extremely* cautious doing such a
>>(insn 1 0 2 0 (set (reg/v:Xmode r)
>>(sign_extend:Xmode (op:Ymode (...
>>(insn 2 1 3 0 (set (lhs) (rhs)))
> 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 e
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)
> + {
> +
Hello,
I'm working on a the sign extension elimination pass.
(see http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01087.html for details)
I would like to merge these two instructions:
(insn 1 0 2 0 (set (reg/v:Xmode r)
(sign_extend:Xmode (op:Ymode (...
(insn 2 1 3 0 (set (lhs) (rhs)))
w
11 matches
Mail list logo
