From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-118484-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 32129 invoked by alias); 21 Aug 2005 17:54:01 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 32068 invoked by uid 22791); 21 Aug 2005 17:53:57 -0000
Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.29.150)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 21 Aug 2005 17:53:57 +0000
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j7LHrsOI155122
	for <gcc@gcc.gnu.org>; Sun, 21 Aug 2005 17:53:54 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7LHrsKF137248
	for <gcc@gcc.gnu.org>; Sun, 21 Aug 2005 19:53:54 +0200
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j7LHrslN026438
	for <gcc@gcc.gnu.org>; Sun, 21 Aug 2005 19:53:54 +0200
Received: from d12ml102.megacenter.de.ibm.com (d12ml102.megacenter.de.ibm.com [9.149.166.138])
	by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j7LHrsmg026435;
	Sun, 21 Aug 2005 19:53:54 +0200
In-Reply-To: <Pine.LNX.4.44.0508211022100.21895-100000@www.eyesopen.com>
To: Roger Sayle <roger@eyesopen.com>
Cc: gcc@gcc.gnu.org, Mircea Namolaru <NAMOLARU@il.ibm.com>
MIME-Version: 1.0
Subject: Re: Question about merging two instructions.
From: Leehod Baruch <LEEHOD@il.ibm.com>
Message-ID: <OFB3CF453F.B7E4DC69-ONC2257064.005F5FD0-C2257064.00627321@il.ibm.com>
Date: Sun, 21 Aug 2005 17:54:00 -0000
Content-Type: text/plain; charset="US-ASCII"
X-SW-Source: 2005-08/txt/msg00565.txt.bz2

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

I want to replace every use of (reg r) with the extension.  There might 
be such use on the LHS, this is why the LHS might change.

1. Can you please give me an example of something bad that can happen to 
the LHS.  Maybe I'm missing something here.

2. After calling simplify_replace_rtx I try to recognize the instruction.
Is this been cautious or is it unnecessary?

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.


Thanks,
Leehod.