This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: proposal to make SIZE_TYPE more flexible

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]