This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] Fight dependencies in C front end on middle-end include files
- From: Diego Novillo <dnovillo at google dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 15 May 2010 13:15:24 -0400
- Subject: Re: [RFC] Fight dependencies in C front end on middle-end include files
- References: <AANLkTimS3QWT7fx9zhbc6ryvUR6luy01tdCB6LzaCYVq@mail.gmail.com>
On Sat, May 15, 2010 at 11:48, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> As part of an effort to make GCC more modular, we will have to figure
> out what really depends on what, to make sure we can properly define
> the boundaries of modules and move code where it belongs. For example,
> a front end should not have to know about gimple except at the
> interface with the middle-end, a front end should not have to know
> about RTL at all. But it does need to know about target hooks, etc.
Agreed. Along these lines, how about making header files hermetic so
that they can be included independently of other header files? For
instance,
> +#ifndef GCC_VECIR_H
> +#define GCC_VECIR_H
> +
> +#ifndef GCC_CORETYPES_H
> +#error "vecir.h must be included after coretypes.h"
> +#endif
Here, I'd just include vec.h as well as coretypes.h. Which in turns
means that this becomes the only interface needed to be included from
files that want to handle collections of IR elements.
The middle end parts are OK. Thanks for getting this started.
Diego.