This is the mail archive of the
mailing list for the GCC project.
How to tag frontend-specific types?
- From: "Laurynas Biveinis" <laurynas dot biveinis at gmail dot com>
- To: "GCC Mailing List" <gcc at gcc dot gnu dot org>
- Cc: "Daniel Berlin" <dberlin at dberlin dot org>
- Date: Tue, 22 Aug 2006 13:22:21 +0300
- Subject: How to tag frontend-specific types?
(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
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
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
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?