From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-41493-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 21517 invoked by alias); 23 Nov 2001 03:56:51 -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 21479 invoked from network); 23 Nov 2001 03:56:43 -0000
Received: from unknown (HELO cygnus.com) (205.180.230.5)
  by sourceware.cygnus.com with SMTP; 23 Nov 2001 03:56:43 -0000
Received: from tornado.toronto.redhat.com (tornado.toronto.redhat.com [172.16.14.228])
	by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id TAA13185;
	Thu, 22 Nov 2001 19:56:35 -0800 (PST)
Received: (from dnovillo@localhost)
	by tornado.toronto.redhat.com (8.11.6/8.11.2) id fAN3uWn32604;
	Thu, 22 Nov 2001 22:56:32 -0500
Date: Tue, 13 Nov 2001 13:41:00 -0000
From: Diego Novillo <dnovillo@redhat.com>
To: law@redhat.com
Cc: dan@cgsoftware.com, gcc@gcc.gnu.org
Subject: Re: Higher level RTL issues
Message-ID: <20011122225632.A30650@tornado.cygnus.com>
References: <22136.1003775535@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <22136.1003775535@localhost.localdomain>; from law@redhat.com on Mon, Oct 22, 2001 at 12:32:15 -0600
Organization: Red Hat Canada
X-SW-Source: 2001-11/txt/msg00612.txt.bz2

[ Apologies for joining so late.  I've been away for a month. ]

On Mon, 22 Oct 2001, Jeff Law wrote:

> So how is this done when SSA names are not reflected in the IR?  I have
> ideas, but I'd like to hear from someone with more experience in the
> non-rewriting camp.  You certainly can't do the naive thing and drop the
> SSA names in favor of the original names.
> 
In the non-rewriting SSA there are no names to drop.  There is no
SSA->normal translation because the SSA data structure is simply
laid on top of the flow graph.

However, eliminating redundancy does force you to update the SSA
web.  The work you have to do is similar to the work you would do
manipulating the SSA names.

> When we reach insn 458, we lookup (sign_extend:DI (reg:SI 343)) and we
> get (reg:DI 444).  Cool.  That means insn 458 is redundant.  Delete it.
> Do some manipulation of our renaming stacks to arrange for uses of 
> (reg:DI 617) to be rewritten as (reg:DI 444).  The only uses of 
> (reg:DI 617) are at insn 765.
>
The above transformation in the non-rewriting SSA goes like this:

When you decide to eliminate insn 458, instead of doing a
manipulation of the renaming stacks, you just manipulate the
use-def and def-use links between the def of r344 at bb 18 and
the phi term for r344 at bb 23.

This is the original phi term:

(insn 765 744 276 (set (reg:DI 603)
        (phi[
                (reg:DI 617)
                (const_int 22 [0x16])
                (reg:DI 617)
                (const_int 21 [0x15])
                (reg:DI 617)
                (const_int 20 [0x14])
                (reg:DI 617)
                (const_int 19 [0x13])
                (reg:DI 614)
                (const_int 16 [0x10])
                (reg:DI 607)
                (const_int 9 [0x9])
                (reg/v:DI 344)
                (const_int 7 [0x7])
            ] )) -1 (nil)
    (nil))

In this case, all the arguments for r617 are actually pointers to
the definition for r344 at insn 458.  Since insn 458 is being
removed, you simply make those use-def links point to the
definition for r444 in insn 305.  This operation is akin to
manipulating the renaming stacks you have to do in the rewriting
form.


Diego.