Re: Converting tm.h macros to functions

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Sun, 17 Jun 2001, Neil Booth wrote:

> I think we should have a "struct target_os" and a "struct target_cpu"
> (I think that's all there is to being a target?) where we can define
> stuff like this, and require targets to define them appropriately.
> Having one or two humungous structs like this is probably not a good
> idea, so they would need to be divided up in a logical way somehow.

The problem with using structures here is that we don't want to have to 
change every back end (many more than there are front ends) when we add a 
new function (which we want to do in the most logical place in the 
structure), but we can't rely on C99 designated initialisers in the host 
compiler.  You could require targets to define a target_init function (is 
there currently any corresponding macro?) that initialises all values that 
are non-default.  (So, in the typical case of a new hook only relevant at 
first to a few targets, all the rest need not change.)

> In other words, I think you should have function pointers, with a NULL
> meaning "not interested" if this is meaningful for the function in
> question, much like the hooks stuff I did in toplev.h
> (e.g. post_options() can be NULL).  The default functions should be
> exported and be collected in a header file so that the target files
> can include it, and use the defaults if they want, or maybe override
> the defaults and possibly call the default later (like inheritance in
> C++).

FWIW, the ones I want to do are those concerned with machine-dependent
attributes (MERGE_MACHINE_TYPE_ATTRIBUTES, MERGE_MACHINE_DECL_ATTRIBUTES,
VALID_MACHINE_DECL_ATTRIBUTE, ...).  In most cases the targets do define 
the macros just to call a function, but it would be cleaner to use 
function pointers explicitly.  (Some of the target functions do indeed 
call the default merge_attributes.)

One problem with function pointers: Texinfo's @deftypefn and similar 
commands presume that the type comes entirely before the function name, so 
rather than

@deftypefn {Target Hook} tree merge_machine_decl_attributes (tree @var{t1}, tree @var{t2})

you'd have

@deftypefn {Target Hook} {tree (*} target_hooks.merge_machine_decl_attributes )(tree @var{t1}, tree @var{t2})

which represents the type less accurately and looks worse in the output.
Or you could cheat and pretend the structure elements are functions rather
than pointers to functions.

-- 
Joseph S. Myers
jsm28@cam.ac.uk