From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20552 invoked by alias); 14 Jan 2010 09:44:58 -0000 Received: (qmail 20544 invoked by uid 22791); 14 Jan 2010 09:44:56 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail.intrepid.com (HELO mail.intrepid.com) (74.95.8.113) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 14 Jan 2010 09:44:50 +0000 Received: from screamer.local (screamer.local [10.10.1.2]) by mail.intrepid.com (8.13.8/8.13.8) with ESMTP id o0E9in3e031630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jan 2010 01:44:49 -0800 Received: from screamer.local (screamer.local [127.0.0.1]) by screamer.local (8.14.3/8.14.3) with ESMTP id o0E9inEP018710; Thu, 14 Jan 2010 01:44:49 -0800 Received: (from gary@localhost) by screamer.local (8.14.3/8.14.3/Submit) id o0E9inLE018709; Thu, 14 Jan 2010 01:44:49 -0800 Date: Thu, 14 Jan 2010 09:44:00 -0000 From: Gary Funck To: Richard Guenther Cc: GCC List Subject: Re: RFC: cgraph/lowering vs. finish_file for GCC/UPC rewrites? Message-ID: <20100114094449.GA15400@intrepid.com> References: <20090914011819.GF7654@intrepid.com> <84fc9c000909140252p3c9ad031wa3279dfd82541b2c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84fc9c000909140252p3c9ad031wa3279dfd82541b2c@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-01/txt/msg00295.txt.bz2 On 09/14/09 11:52:11, Richard Guenther wrote: > > What approach would you recommend for the > > implementation of UPC tree re-writes that will > > support calls to the runtime (that are inlined, > > if applicable)? > > Without reading all the details of your mail I suggest that you > perform a custom walk over the function bodies right before > the frontend calls cgraph_finalize_compilation_unit () that > performs the necessary lowering (and function creation) to > GENERIC. The C++ frontend already does this during its > genericize phase to transform frontend specific trees to > middle-end GENERIC trees. I tried the custom tree walk approach, but decided that it will require some of the infrastructure already present in the gimplify pass (e. g., the creation of temp. variables), and that it is more expedient to utilize the current language dependent gimplify hook, but to move it earlier in the processing of the function body. To that end, I defined a language dependent genericize hook: /* Determine if a tree is a function parameter pack. */ bool (*function_parameter_pack_p) (const_tree); + /* Genericize before finalization (called from finish_function()). + Perform lowering of function bodies from language dependent form + to language independent (GENERIC) form. */ + void (*genericize) (tree); + which is called from finish_function (instead of calling c_genericize): if (!decl_function_context (fndecl)) { invoke_plugin_callbacks (PLUGIN_PRE_GENERICIZE, fndecl); - c_genericize (fndecl); + /* Lower to GENERIC form before finalization. */ + lang_hooks.genericize (fndecl); The UPC genericize hook is implemented as: /* Convert the tree representation of FNDECL from UPC frontend trees to GENERIC. */ void upc_genericize (tree fndecl) { /* Take care of C-specific actions first. Normally, we'd do this after the language-specific actions, but c_genericize is only a dumping pass now, and should be renamed. */ c_genericize (fndecl); /* Perform a full gimplify pass, because the UPC lowering rewrites are implemented using the gimplify framework. */ gimplify_function_tree (fndecl); } Although this may not be the best fit with the current framework, it lets us re-use the gimplify pass that we have been using with previous GCC 4.x implementations. At some point, we'll need to develop a ground-up tree-walk rewrite pass.