> (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).
The complications I've seen there is, for example, when you're iterating through types looking for a "best" type, where some of the types are fixed foo_type_node's and others are dynamic intN_type_nodes. Perhaps we sould use a hybrid list-plus-table approach? So we check for the standard types explicitly, then iterate through the list of intN types? > I can also believe it's appropriate for the global nodes for trees > reflecting C ABI types to go somewhere other than tree.h. Which are those? Why isn't "int" one of those? > 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. If you want to support more than one intN at a time, IMHO you need more than just one intN object, hence a table of some sort. Or are you assuming that any given backend would only be allowed to define one intN type? That's already not going to work, as I need int20_t in addition to the "now standard" int128_t. > 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. How is this different than the places handling hardcoded lists of integer_type_node et al? > 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. Yeah, I'm not trying to take on more work, just trying to hit the prereqs for my own project.
