From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-56923-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 22882 invoked by alias); 22 Jul 2002 07:25:37 -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 22808 invoked from network); 22 Jul 2002 07:25:35 -0000
Received: from unknown (HELO executor.cambridge.redhat.com) (195.224.55.237)
  by sources.redhat.com with SMTP; 22 Jul 2002 07:25:35 -0000
Received: from prospero.cambridge.redhat.com (dell-paw-2.cambridge.redhat.com [195.224.55.226])
	by executor.cambridge.redhat.com (Postfix) with ESMTP
	id EF059ABAF8; Mon, 22 Jul 2002 08:25:34 +0100 (BST)
Received: by prospero.cambridge.redhat.com (Postfix, from userid 4046)
	id DC5DBF83C1; Mon, 22 Jul 2002 08:21:52 +0100 (BST)
To: Daniel Berlin <dberlin@dberlin.org>
Cc: "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
	Jason Merrill <jason@redhat.com>, Diego Novillo <dnovillo@redhat.com>
Subject: Re: Language-independent functions-as-trees representation
References: <Pine.LNX.4.44.0207220210010.14956-100000@dberlin.org>
From: Jason Merrill <jason@redhat.com>
In-Reply-To: <Pine.LNX.4.44.0207220210010.14956-100000@dberlin.org> (Daniel
 Berlin's message of "Mon, 22 Jul 2002 02:20:36 -0400 (EDT)")
Date: Mon, 22 Jul 2002 07:18:00 -0000
Message-ID: <wvlsn2cfcrz.fsf@prospero.cambridge.redhat.com>
User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.1 (i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2002-07/txt/msg01012.txt.bz2

>>>>> "Daniel" == Daniel Berlin <dberlin@dberlin.org> writes:

> On Sun, 21 Jul 2002, Jason Merrill wrote:

>> The current simplification code explicitly unshares all the trees to avoid
>> SAVE_EXPR-like problems with shared expressions.

> Not all of them. Or at least, if it should, it's buggy.

> From a SSAPRE dump:
> In BB 111, insert save of la - lb to pretmp.4753 in statement T.4530 = la 
> - lb on line 2047
> In BB 135, insert reload of la - lb from pretmp.4753 in statement T.4676 = 
> la - lb on line 2091
> In BB 136, insert reload of la - lb from pretmp.4753 in statement T.4530 = 
> pretmp.4753 = la - lb on line 2047

> The last one occurs because, once simplified, we have:
>     for (T.4530 = la - lb; j <= T.4530; T.4530 = la - lb)
>         {

> Where the T.4530 = la - lb 's are shared.

They shouldn't be; we do a deep_copy_list so the two copies will be
unshared.

I'm feeling pretty dubious about this duplication, though.  Any duplication
of code should be done for reasons of optimization, not to try to shoehorn
the simplified code into C loop forms.  So instead of simplifying

for (; j <= la - lb;)
  { body }

that way, I think we should simplify it to

while (true)
  {
    T.4530 = la - lb;
    if (j <= T.4530)
      { body }
  }

and let loop optimization deduce an induction variable later, if it can.
I have similar issues with the insert_before_continue_end stuff.

Jason