From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6756 invoked by alias); 24 Jul 2002 01:29:14 -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 6749 invoked from network); 24 Jul 2002 01:29:13 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 24 Jul 2002 01:29:13 -0000 Received: from dot.sfbay.redhat.com (dot.sfbay.redhat.com [172.16.24.7]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g6O1TVQ24992; Tue, 23 Jul 2002 18:29:31 -0700 Received: (from rth@localhost) by dot.sfbay.redhat.com (8.11.6/8.11.6) id g6O1TCT23896; Tue, 23 Jul 2002 18:29:12 -0700 X-Authentication-Warning: dot.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Wed, 24 Jul 2002 03:01:00 -0000 From: Richard Henderson To: Jason Merrill Cc: Diego Novillo , Per Bothner , Mark Mitchell , gcc@gcc.gnu.org Subject: Re: Language-independent functions-as-trees representation Message-ID: <20020723182912.A23891@redhat.com> Mail-Followup-To: Richard Henderson , Jason Merrill , Diego Novillo , Per Bothner , Mark Mitchell , gcc@gcc.gnu.org References: <20020722210212.GA16149@tornado.toronto.redhat.com> <20020723105753.B23600@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from jason@redhat.com on Wed, Jul 24, 2002 at 01:14:06AM +0100 X-SW-Source: 2002-07/txt/msg01135.txt.bz2 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. > 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 +? > Of course, that we don't currently make any attempt to take advantage of > this opportunity could suggest that indeed it isn't very useful... It's also a hard problem, so I don't think that's necessarily true. 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. r~