On Fri, 22 Nov 2013, DJ Delorie wrote: > > (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?
In general you need to analyze each such case individually to produce a reasoned argument for what it should logically be doing. Given such analyses, maybe then you can identify particular tables of types in particular orders (for example) that should be set up to iterate through. > > 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 think "int" is one of them. Those files that have a need for C ABI types would include tree-c-abi.h. Optimizers that aren't e.g. generating calls to built-in functions where the C ABI is involved wouldn't include that header. As this should be orthogonal to your project it could just as well be part of the tree.h cleanup project. > > 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 saying that the starting point is understanding what is logically correct in the various different places dealing with integer types, and an analysis of that is what must drive any API design. Does the target with __int20 actually have __int128 (i.e. pass targetm.scalar_mode_supported_p (TImode))? But you should indeed be able to have an arbitrary number of such types. > > 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? (a) We already have the system for an arbitrary set of integer modes to be defined and iterated over, whereas the set of standard C types is target-independent. (b) This sort of thing tends to be more readily addressed through a series of small cleanup patches that clearly isolate anything that might possibly change behavior at all than through one huge patch. So any small obvious things are naturally separated out. (c) Iteration over C types has other complications such as preferences between different types (e.g. int and long) with the same middle-end properties. (d) I don't think the standard C types are particularly relevant to your project. -- Joseph S. Myers jos...@codesourcery.com
