Re: GTY / gengtype question - adding a new header file

[Richard Sandiford <rdsandiford at googlemail dot com>]

"Steve Ellcey " <sellcey@imgtec.com> writes:
> I have a question about gengtype and GTY.  I was looking at adding some
> code to mips.c and it occurred to me that that file was getting very
> large (19873 lines).  So I wanted to add a new .c file instead but that
> file needed some types that were defined in mips.c and not in a header file.
> Specifically it needed the MIPS specific machine_function structure that
> is defined in mips.c with:
>
> struct GTY(())  machine_function {....
>
> I think I could just move this to mips.h and things would be fine but
> I didn't want to do that because mips.h is included in tm.h and is visible
> to the generic GCC code.  Currently machine_function is not visible to the
> generic GCC code and so I wanted to put machine_function in a header file
> that could only be seen/used by mips specific code.  So I created
> mips-private.h and added it to extra_headers in config.gcc.
>
> The problem is that if I include mips-private.h in mips.c instead of
> having the actual definition of machine_function in mips.c then my
> build fails and I think it is due to how and where gengtype scans for GTY
> uses.
>
> I couldn't find an example of a platform that has a machine specific header
> file that was not visible to the generic GCC code and that has GTY types
> in it so I am not sure what I need to do to get gengtype to scan
> mips-private.h or if this is even possible (or wise).

config.gcc would need to add mips-private.h to target_gtfiles.

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.

I'm also a bit worried that if more ports go down this path, each port
will have its own conventions for what goes where.  That just makes
life harder for people who want to change a target interface and need
to touch all targets.

We already have that problem to some extent when it comes to whether
targetm is initialised at the head of the file, using forward static
declarations, or at the end, with no need for forward declarations.
As Joseph said in old post, if we switched all targets to using the
latter form, converting macros to hooks would become almost automatic.
Spltting the port would make it more manual again.

None of those are killer arguments, but I'm not sure there's a killer
argument for the split either.  It would speed up a rebuild in which
only part of mips.c has changed, but it doesn't take that long to build.

I think we'd only get an "elegant" and consistent split if the target
interface itself was split, rather than being one monolithic structure.

Thanks,
Richard