This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: proposal to make SIZE_TYPE more flexible
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: DJ Delorie <dj at redhat dot com>, <gcc at gcc dot gnu dot org>
- Date: Sat, 16 Nov 2013 12:26:02 +0000
- Subject: Re: proposal to make SIZE_TYPE more flexible
- Authentication-results: sourceware.org; auth=none
- References: <201310300422 dot r9U4M6Mx002568 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1310301535400 dot 22878 at digraph dot polyomino dot org dot uk> <201310301917 dot r9UJHxg7028662 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1310302035190 dot 29408 at digraph dot polyomino dot org dot uk> <201310302219 dot r9UMJg9e001309 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1310302249250 dot 29408 at digraph dot polyomino dot org dot uk> <201311140158 dot rAE1wCkg006136 at greed dot delorie dot com> <Pine dot LNX dot 4 dot 64 dot 1311141318300 dot 21407 at digraph dot polyomino dot org dot uk> <201311152338 dot rAFNc9CJ007961 at greed dot delorie dot com> <b69fa903-a837-4d4e-aa00-c2a22b06c1c4 at email dot android dot com>
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
joseph@codesourcery.com