From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4049 invoked by alias); 23 Jul 2002 17:57:54 -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 4042 invoked from network); 23 Jul 2002 17:57:54 -0000 Received: from unknown (HELO potter.sfbay.redhat.com) (205.180.83.107) by sources.redhat.com with SMTP; 23 Jul 2002 17:57:54 -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 g6NHwDQ22630; Tue, 23 Jul 2002 10:58:13 -0700 Received: (from rth@localhost) by dot.sfbay.redhat.com (8.11.6/8.11.6) id g6NHvr823609; Tue, 23 Jul 2002 10:57:53 -0700 X-Authentication-Warning: dot.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Tue, 23 Jul 2002 19:07: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: <20020723105753.B23600@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> 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 Tue, Jul 23, 2002 at 06:01:21PM +0100 X-SW-Source: 2002-07/txt/msg01119.txt.bz2 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. > > 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. > 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. What other benefits do we get from the complexity of expressing the partial ordering of expressions? r~