From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27601 invoked by alias); 24 Jul 2002 00:19:15 -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 27578 invoked from network); 24 Jul 2002 00:19:12 -0000 Received: from unknown (HELO executor.cambridge.redhat.com) (195.224.55.237) by sources.redhat.com with SMTP; 24 Jul 2002 00:19:12 -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 CFFFCABAF8; Wed, 24 Jul 2002 01:19:07 +0100 (BST) Received: by prospero.cambridge.redhat.com (Postfix, from userid 4046) id E156AF8D67; Wed, 24 Jul 2002 01:14:07 +0100 (BST) To: Richard Henderson Cc: Diego Novillo , Per Bothner , Mark Mitchell , gcc@gcc.gnu.org Subject: Re: Language-independent functions-as-trees representation References: <20020722210212.GA16149@tornado.toronto.redhat.com> <20020723105753.B23600@redhat.com> From: Jason Merrill In-Reply-To: <20020723105753.B23600@redhat.com> (Richard Henderson's message of "Tue, 23 Jul 2002 10:57:53 -0700") Date: Tue, 23 Jul 2002 23:40: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/msg01129.txt.bz2 >>>>> "Richard" == Richard Henderson writes: > On Tue, Jul 23, 2002 at 06:01:21PM +0100, Jason Merrill wrote: >> On the other hand, going from INITIAL to GENERIC will use a lot of the same >> functionality as from GENERIC to SIMPLE, so perhaps it would be simpler >> just to go straight to SIMPLE, using a langhook to handle language-specific >> trees. > I think I like this idea. I can't imagine except that it'd be > faster, and use less memory in the process. I would think. >> > But we need to know whether a tree >> > node affects flow of control or not. That's important >> > for building the flowgraph. >> >> 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 think we also need something to express the absence of ordering >> restrictions. If we write f(g(), h()), there will be a sequence point >> after each of the calls to g and h (at least in C++). Or if they're >> inlined, within the calls. We need to make it explicit that despite the >> presence of sequence points, the optimizer can switch the two around. >> That's why I was suggesting something like UNORDERED_LIST. > Alternately, the number of places in which this applies seems > relatively limited. We might be able to do with a langhook > that says what order in which arguments may be evaluated. That could be useful at simplification time, but not after; once we've simplified, all the arguments are temporary variables or constants, and their evaluations are serialized. Likewise for arithmetic operands. 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. > What other benefits do we get from the complexity of expressing > the partial ordering of expressions? I would imagine that there could be some benefit to reordering evaluation to reduce exception regions for temporary cleanups, or to bring instances of a common subexpression closer together in the codestream, or whatever. 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... Jason