This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Unreviewed patches
- From: Paul Schlie <schlie at comcast dot net>
- To: Zack Weinberg <zack at codesourcery dot com>
- Cc: Alexandre Oliva <aoliva at redhat dot com>,Richard Sandiford <rsandifo at redhat dot com>,<gcc-patches at gcc dot gnu dot org>
- Date: Tue, 29 Mar 2005 20:37:08 -0500
- Subject: Re: Unreviewed patches
> Zack Weinberg <zack at codesourcery dot com>
>> Alexandre Oliva <aoliva@redhat.com> writes:
>>> I'm also of the opinion that the c4x port is wrong in making QImode
>>> be 32 bits wide; that it should instead leave SImode at its usual
>>> size and not use QI or HI modes at all.
>>
>> This doesn't make sense. BITS_PER_UNIT defines the minimal-sized
>> addressable unit, and AFAIK that's 32 bits for c4x. QImode is, by
>> definition, an integer type whose width is BITS_PER_UNIT.
>
> The problem is that there are conflicting definitions here. SImode is
> currently defined (by specification) as the integer type whose width
> is 4*BITS_PER_UNIT, but it is also defined (by expectation) as the
> integer type whose width is as near to 32 bits as is possible. One of
> these things has to give, and I'm of the belief that it is less
> trouble to change the specification than the expectations.
For good or bad, GCC is heavily biased toward assuming that QI == 8 bits,
and that HI, SI, and DI modes are corresponding multiples of that basic
presumption; therefore the c4x port should likely define BITS_PER_UNIT =
SIZE_OF_CHAR = SIZE_OF_SHORT = SIZE_OF_INT == 32 == SImode, and
correspondingly UNITS_PER_WORD = 1. (As there seem no upside to choosing
otherwise, other than asking for headaches, from the best I can tell.)
If helpful, I've already submitted a patch for review which eliminates
libgcc2.h's inappropriate attempt to determine the type mode sizes for
various targets based on definitions of BITS_PER_UNIT and UNITS_PER_WORD,
and instead determine type mode requirements based upon a targets defined
type sizes directly. (presuming the above relationships, just as the bulk
of GCC does)