proposal to make SIZE_TYPE more flexible

[Joseph S. Myers]

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
joseph@codesourcery.com