On 02/18/2018 12:10 PM, Joseph Myers wrote:
On Sun, 18 Feb 2018, Sandra Loosemore wrote:
So what is the purpose of having a separate $target-protos.h?
It looks like the original explanation was
<https://gcc.gnu.org/ml/gcc-patches/1999-09n/msg00866.html>, "Because
tm_p.h needs to be included after tree.h and rtl.h.".
It's certainly still true that rtl.h requires tm.h to have been included
first. It's also true that tm_p.h depends on types beyond those for which
simple forward declarations suffice - for example, the machine_mode enum
(and now the various classes related to machine modes). So maybe in 1999
there would have been circular dependencies on types from tree.h and
rtl.h.
Thanks, this makes sense. I think I could produce a documentation patch
that explains that the difference is early vs late inclusion, and
explains that any declarations involving tree or rtx types must go in
$target-protos.h because those types are not defined when $target.h is
included.
Now more things are included in coretypes.h (including e.g. the
machine_mode enum via insn-modes.h). I don't know if circular dependency
issues would still arise; any global move of prototypes into tm.h would
require building cc1 for all architectures to locate any such problems.
(Presumably the prototypes would also all need to be disabled for
USED_FOR_TARGET.)
I don't really want to go there, but maybe target maintainers might want
to do that when Stage 1 re-opens.
An alternative to adding more tm_p.h includes or moving prototypes into
tm.h would be, if there are only a few target macros involved, converting
those target macros into hooks.
Yup, although again this is Stage 1 material.
So am I right in thinking it is actually not possible to have a .h file
for internal bits shared between $target.c and the .md files, without
hacking e.g. genrecog.c which currently emits a fixed set of include
directives?
-Sandra
