On Sat, 16 Nov 2013, Richard Biener wrote: > >I did a scan through the gcc source tree trying to track down all the > >implications of this, and there were a lot of them, and not just the > >RID_* stuff. There's also the integer_types[] array (indexed by > >itk_*, which is its own mess) > > I don't think we need this. It shoul be split into frontend parts and > what we consider part of the C ABI of the target.
Indeed, most middle-end references to particular C types are suspect (and likewise references to particular modes such as SImode, other than QImode which is always the target byte of BITS_PER_UNIT bits). As regards the ABI, I've previously suggested a hook taking a subset of itk_* values are a replacement for target macros such as INT_TYPE_SIZE (cf Joern's patches, Nov/Dec 2010, and note that in various places it may be better to use TYPE_PRECISION (integer_type_node) etc. if the type nodes have been initialized by then). But such a hook doesn't need to handle __intN types since it's part of the definition of __intN that it takes N bits. I suppose global type nodes may be needed outside front ends for dealing with built-in function interfaces if nothing else, but for __intN you might get an interface "return the signed / unsigned __intN type" rather than macros like int128_integer_type_node. (Looking at some examples of middle-end code inappropriately using particular C ABI types: the code in tree-ssa-loop-ivopts.c needs some way to iterate over "integer types that are efficient on the target"; what types the ABI says are int / long / long long should be irrelevant. Code in convert.c is an example of a trickier case, where the enums for built-in functions embed information about the integer and floating-point types involved and a better way would be needed to extract the underlying operation for a built-in function and identify the function, if any, for an arbitrary type or pair of types.) -- Joseph S. Myers jos...@codesourcery.com
