This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] CFG hooks for rtl/tree specificities
- From: Jan Hubicka <jh at suse dot cz>
- To: Pop Sébastian <pop at gauvain dot u-strasbg dot fr>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 1 Apr 2003 17:46:07 +0200
- Subject: Re: [RFC] CFG hooks for rtl/tree specificities
- References: <20030401145007.GA25362@gauvain.u-strasbg.fr>
> 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