$target.h vs $target-protos.h

[Georg-Johann Lay]

Sandra Loosemore schrieb:
> 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?

IIRC, one difference is scanning for GTY markers used to tag ggc roots: 
$target.h is scanned whereas $target-protos.h is not (and AFAIR adding 
$target-protos.h in config.gcc to the files being scanned pops up other 
problems). Hence when you have a target-specific GTYed structure that's 
shared by several back-end modules, you'd add the struct definition to 
$target.h (If only one module needs such objects, then you'd add the 
type definition to, say, $target.c which is scanned — or can be rendered 
to a scanned one by adjusting config.gcc).

The bulk of code is not GTYed, of course, and from my experience the 
usage of the mentioned files is like you summarized: $target-protos.h is 
usually a blob of prototypes used internally to communicate within a 
back-end, whereas $target.h "defines" the backend part that's not yet 
hookized, e.g. the TARGET_ macros that define (initializers for) 
register classes etc.

And the usage in libgcc might be different: $target.h is used in libgcc 
(which is the reason for why $target.h might need runtime library 
exceptions, cf. PR61152: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152#c0 ) Ideally, all 
information needed by libgcc and other target libraries would be shipped 
by built-in macros, but such complete separation from compiler sources 
from libgcc sources is not yet complete to the best of my knowledge. 
$target-protos.h (via tm_p.h), however, is not used by libgcc.

Johann

> 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