This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: GTY / gengtype question - adding a new header file
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Steve Ellcey <Steve dot Ellcey at imgtec dot com>, Georg-Johann Lay <avr at gjlay dot de>, Richard Sandiford <rdsandiford at googlemail dot com>, "Moore, Catherine (Catherine_Moore at mentor dot com)" <Catherine_Moore at mentor dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 1 Sep 2015 22:05:11 +0000
- Subject: RE: GTY / gengtype question - adding a new header file
- Authentication-results: sourceware.org; auth=none
- References: <57fd9168-0c14-4556-8790-17d7695c8752 at BAMAIL02 dot ba dot imgtec dot org> <55E55E29 dot 4070208 at gjlay dot de> <1441126226 dot 26051 dot 42 dot camel at ubuntu-sellcey>
Steve Ellcey <Steve.Ellcey@imgtec.com> writes:
> On Tue, 2015-09-01 at 10:13 +0200, Georg-Johann Lay wrote:
>
> >
> > I'd have a look at what BEs are using non-default target_gtfiles.
> >
> > Johann
>
> There are a few BEs that add a .c file to target_gtfiles, but no
> platforms that add a .h file to target_gtfiles. I do see a number
> of platforms that define the machine_function structure in their header
> file (aarch64.h, pa.h, i386.h) instead of their .c file though.
>
> Maybe that is a better way to go for MIPS instead of doing something
> completely new. If I move machine_function, mips_frame_info,
> mips_int_mask, and mips_shadow_set from mips.c to mips.h then I could
> put my new machine specific pass in a separate .c file from mips.c and
> not need to do anything with target_gtfiles. The only reason I didn't
> want to do this was so that machine_function wasn't visible to the rest
> of GCC but that doesn't seem to have been an issue for other targets.
Personally I quite like the idea of separating out code if at all possible
so having to expose a bit more of the MIPS backend internals does not
seem like too high a cost.
Matthew