From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29055 invoked by alias); 24 Jul 2002 10:35:06 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 29028 invoked from network); 24 Jul 2002 10:35:01 -0000 Received: from unknown (HELO executor.cambridge.redhat.com) (195.224.55.237) by sources.redhat.com with SMTP; 24 Jul 2002 10:35:01 -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 5F97EABAF8; Wed, 24 Jul 2002 11:35:00 +0100 (BST) Received: by prospero.cambridge.redhat.com (Postfix, from userid 4046) id 78CAAF8D67; Wed, 24 Jul 2002 11:29:45 +0100 (BST) To: Richard Henderson Cc: Diego Novillo , Per Bothner , Mark Mitchell , gcc@gcc.gnu.org, Jason Merrill Subject: Re: Language-independent functions-as-trees representation References: <20020722210212.GA16149@tornado.toronto.redhat.com> <20020723105753.B23600@redhat.com> <20020723182912.A23891@redhat.com> From: Jason Merrill In-Reply-To: <20020723182912.A23891@redhat.com> (Richard Henderson's message of "Tue, 23 Jul 2002 18:29:12 -0700") Date: Wed, 24 Jul 2002 11:34:00 -0000 Message-ID: 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/msg01154.txt.bz2 >>>>> "Richard" == Richard Henderson writes: > On Wed, Jul 24, 2002 at 01:14:06AM +0100, Jason Merrill wrote: >> >> Well, anything that can trap affects flow of control; in C++, most >> >> function calls have edges to the local exception handler. In Java, some >> >> arithmetic does as well. >> >> > Yes, but I'd say that traping arithmetic cannot be a nested expression. >> > It would only be able to appear as the statement "t = a op b". Perhaps >> > similarly with trapping memory references. >> >> In SIMPLE that's as complex as any expression gets. > I guess I don't see your point then. My point was just that affecting the flow of control is not a difference between statements and expressions. >> It may well be that the optimization opportunities from switching operand >> evaluation around at a later phase of optimization are small compared to >> the complexity of representing it. But the complexity is also small; an >> initial implementation could just treat UNORDERED_LIST like >> COMPOUND_STMT/EXPR. > That's a highly simplified representation of unsequenced expressions. > Is it enough to represent > (a++, a + 2) + (b++, b + 3) > which has two ordered pairs, but no ordering across the +? Sure: unordered_list ( (a = a + 1, t1 = a + 2), (b = b + 1, t2 = b + 3) ) t3 = t1 + t2 > At the same time, I do think there's probably little to be gained. > Certainly not enough to justify the complexity that I sense is > associated with the problem. Indeed, I think that most of the > possible benefit would come in the form of relaxed scheduling > constraints, which would mean tracking this partial ordering all > the way through the optimizers. Which is pretty much a non-starter. Fair enough. Jason