$target.h vs $target-protos.h

[Sandra Loosemore]

The internals manual says that a backend for $target should have 
$target.h and $target-protos.h files, but doesn't say what the 
difference between them is or what belongs in which file.  Current 
practice seems to be a mix of


(1) $target.h contains macro definitions and $target-protos.h contains 
extern declarations.


(2) $target.h defines the external interface to the backend (the macros 
documented in the internals manual) and $target-protos.h contains things 
shared between $target.c and the various .md files.


But some generic source files include $target.h only and some source 
files include both, which wouldn't be true if either of the above models 
applied.  So is there some other logical way to explain the difference 
and what goes where?


The thing that got me thinking about this is looking at a new port 
originally written by a customer, where it seems like there is too much 
stuff in $target.h.  Then I started chasing it down


- FUNCTION_BOUNDARY depends on which arch variant is being compiled for

- Its expansion references some internal target data structures and 
enumerators to look up that info


- The default definition of TARGET_PTRMEMFUNC_VBIT_LOCATION uses 
FUNCTION_BOUNDARY


- ipa-prop.c uses TARGET_PTRMEMFUNC_VBIT_LOCATION but doesn't include 
$target-protos.h


- tree.c also uses FUNCTION_BOUNDARY directly without including 
$target-protos.h


- Probably there are many other target macros that potentially have 
similar issues


- Presumably this means everything referenced in the expansion of any 
target macro in $target.h also needs to be declared in $target.h and not 
depend on $target-protos.h also being included at the point of use.


So what is the purpose of having a separate $target-protos.h?

-Sandra the confused

Re: $target.h vs $target-protos.h

[Joseph Myers]

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 
, "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.

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.)

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.

-- 
Joseph S. Myers
jos...@codesourcery.com

gcc-8-20180218 is now available

[gccadmin]

Snapshot gcc-8-20180218 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180218/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 257797

You'll find:

 gcc-8-20180218.tar.xzComplete GCC

  SHA256=4f447cb13dd26971b78863c800eac104ae7f19c4748df11b8f237b10d8367637
  SHA1=e02b953089939cd7a8b89993dcd1f57927682e65

Diffs from 8-20180211 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: $target.h vs $target-protos.h

[Sandra Loosemore]

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
, "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