From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25543 invoked by alias); 1 Apr 2003 15:46: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 25536 invoked from network); 1 Apr 2003 15:46:05 -0000 Received: from unknown (HELO nikam.ms.mff.cuni.cz) (195.113.18.106) by sources.redhat.com with SMTP; 1 Apr 2003 15:46:05 -0000 Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107]) by nikam.ms.mff.cuni.cz (Postfix) with SMTP id 325C44DE86; Tue, 1 Apr 2003 17:46:06 +0200 (CEST) Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Tue, 1 Apr 2003 17:46:07 +0200 Date: Tue, 01 Apr 2003 16:23:00 -0000 From: Jan Hubicka To: Pop =?iso-8859-2?Q?S=E9bastian?= Cc: gcc@gcc.gnu.org Subject: Re: [RFC] CFG hooks for rtl/tree specificities Message-ID: <20030401154607.GF904@kam.mff.cuni.cz> References: <20030401145007.GA25362@gauvain.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030401145007.GA25362@gauvain.u-strasbg.fr> User-Agent: Mutt/1.3.28i X-SW-Source: 2003-04/txt/msg00035.txt.bz2 > Hi, > > I would like to have your opinion on the following reorganization of the CFG functions. > > I propose to keep all the functions that deal with IR specificities into a hook structure > a little bit the same way we handle the specificities of a language front-end in langhooks. I like it :) > These functions are initialized during the CFG construction. This would allow the CFG > analyzers and optimizers to work at both the RTL and the tree levels. I think all we need is to have two cfg_hooks pointer and switch betwen cfg_rtl_hooks, cfg_rtl_layout_hooks and cfg_tree_hooks so we don't need to fill up the structure each time. > > > cfghooks.h will contain something like: > ---- > > /* Initializations specific to either the tree or the rtl level. */ > extern void tree_register_cfg_hooks PARAMS ((void)); > extern void rtl_register_cfg_hooks PARAMS ((void)); > > struct cfg_hooks > { > basic_block (*cfgh_split_edge) PARAMS ((edge)); > void (*cfgh_cfg_layout_initialize) PARAMS ((struct loops *)); > void (*cfgh_cfg_layout_finalize) PARAMS ((void)); > void (*cfgh_verify_flow_info) PARAMS ((void)); > }; > > /* The following macros act either at the tree level or at the rtl level. */ > #define split_edge(e) cfg_hooks.cfgh_split_edge (e) > #define cfg_layout_initialize(l) cfg_hooks.cfgh_cfg_layout_initialize (l) > #define cfg_layout_finalize() cfg_hooks.cfgh_cfg_layout_finalize () > #define verify_flow_info() cfg_hooks.cfgh_verify_flow_info () > > extern struct cfg_hooks cfg_hooks; This looks nice. It would be interesting to think about what operations do we really need - for instance split_edge should be probably implementable already via the primitive operations (basic block creation, edge redirection). Our current API is not 100% ready for that so we will probably need cleanup on the way. I would be happy about switching to the hooks first and leaving it to me to cleanup the APIs if you preffer. Honza