This is the mail archive of the
mailing list for the GCC project.
Re: GTY / gengtype question - adding a new header file
- From: Steve Ellcey <sellcey at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Tue, 1 Sep 2015 09:07:09 -0700
- 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> <8737yyobpt dot fsf at googlemail dot com>
- Reply-to: <sellcey at imgtec dot com>
On Tue, 2015-09-01 at 08:11 +0100, Richard Sandiford wrote:
> config.gcc would need to add mips-private.h to target_gtfiles.
OK, that was what I missed.
> I'm not sure splitting the file is a good idea though. At the moment
> the definitions of all target hooks must be visible to a single TU.
> Either you'd need to keep all the hooks in one .c file (leading
> to an artificial split IMO) or you'd need declare some of them
> in the private header. Declaring them in the header file would only be
> consistent if the targetm definition was in its own file (so that _every_
> hook had a prototype in the private header). That seems like unnecessary
> work though.
The code I want to add is actually a separate GCC pass so it breaks out
fairly cleanly. It just needs access to the machine_function structure
and the types and structures included in that structure
(mips_frame_info, mips_int_mask, and mips_shadow_set). It sets a couple
of new boolean variables in the machine_function structure which are
then used during mips_compute_frame_info.
I see what you mean about much of mips.c probably not being splittable
due to the target hook structure but machine specific passes may be the
exception to that rule. We already have one pass in mips.c
(pass_mips_machine_reorg2), that might be something else that could be
broken out, though I haven't looked in detail to see what types or
structures it would need access to.