How to tag frontend-specific types?

["Laurynas Biveinis" <laurynas dot biveinis at gmail dot com>]

Hi all,

(Daniel, now that SoC is over, I guess this is the last my email with
CC: to you, unless you prefer otherwise :)

I'd like to get your feedback about design of frontend-specific type
tag infrastructure in gengtype.

First of all, how things are done currently in WIP version:
1) A big enum is created for all the gengtype-recognized types in
gtype-desc.h, regardless of the frontend they belong to.
2) A big array of function pointers is declared for the same set of
types in gtype-desc.h and initialized in gtype-desc.c with
automatically generated names for marker functions.
3) A new set of marker functions is generated. They are dispatched to
the output files using the common old
get_output_file_with_visibility() logic, i.e. frontend-specific
functions go to the frontend-specific generated files, not
gtype-desc.*.

This setup is flawed: the array in gtype-dec.c is initialized using
function pointers that do not resolve at compilation time. I see
following options how to fix it:

1) Change the big array of function pointers to the linked list of
linked lists, just like GC roots are currently stored. I don't like
this solution at all, because marker function lookup has to be fast.
Included for completeness only.
2) Instead of a single global enum of type tags and corresponding
array of markers, generate one for every frontend. Does GCC have a
long-term plan to have several frontends linked into a single
executable? In this case this solution would need some further
tweaking.
3) Leave single enum and array, but instead of initializing it with
addresses of frontend-specific routines, put placeholders there and
have frontend specific setup routine which would set those pointers to
correct values.
4) Pull all data types from all front ends into gtype-desc.*. Again,
included for completeness, even if this is technically possible.

For me option 2) looks much better than the rest. Are there any
reasons not to implement it?

--
Thanks,
Laurynas