On Fri, 22 Nov 2013, DJ Delorie wrote: > If I come up with some table-driven API to register > "integer-like-types" and search/sort/choose from them, would that be a > good starting point? Then we can #define *_type_node to a function > call perhaps.
I am doubtful that it's appropriate for e.g. integer_type_node to be a function call. I can believe it makes sense for int128_integer_type_node to be such a call (more precisely, for int128_integer_type_node to cease to exist and for any front-end places needing it to call a function, with a type size that should not be a constant 128). I can also believe it's appropriate for the global nodes for trees reflecting C ABI types to go somewhere other than tree.h. I've no idea whether a table-driven API for anything would be a good starting point. That depends on a detailed analysis of the current situation and its deficiencies for whatever you are proposing replacing with such an API. I *am* reasonably confident that the places handling hardcoded lists of intQI_type_node, intHI_type_node, ... would better iterate over whatever supported integer modes may be present in the particular compiler configuration (and have some set of signed / unsigned / atomic types associated with integer modes) rather than hardcoding a list. It would not surprise me if some of the global type nodes either aren't needed at all or, being only used for built-in functions, should actually be defined in builtin-types.def rather than tree.[ch]. For example, complex_integer_type_node and float_ptr_type_node. But I don't think cleaning up those would actually help in any way towards your goal; it would be a completely orthogonal cleanup. -- Joseph S. Myers jos...@codesourcery.com
