Unreviewed patch to tree-ssa-loop-ivopts.c

[Richard Sandiford]

Paul Schlie <schlie@comcast.net> writes:
> From: Richard Sandiford <rsandifo@redhat.com>
>> static void
>> emit_mode_precision (void)
>> {
>>   int c;
>>   struct mode_data *m;
>> 
>>   print_decl ("unsigned short", "mode_precision", "NUM_MACHINE_MODES");
>> 
>>   for_all_modes (c, m)
>>     if (m->precision != (unsigned int)-1)
>>       tagged_printf ("%u", m->precision, m->name);
>>     else
>>       tagged_printf ("%u*BITS_PER_UNIT", m->bytesize, m->name);
>> ---------------------^^^^^^^^^^^^^^^^^
>> 
>>   print_closer ();
>> }
>
> - yup, that would be it. (unfortunately any target defining BITS_PER_UNIT
>   != 8 would then be incompatible with GCC's remaining pervasive assumptions
>   that SI/SF/float and DI/DF/double are equivalently sized). So therefore it
>   seems that the only specification would be consistent with all of GCC's
>   presumptions and definitions for a target like the c4x (without needing to
>   emulate larger/smaller mode operations) would be:
>
>   BITS_PER_UNIT == 8    (only affects bit alignment, w/32 bit char/short's)
>   UNITS_PER_WORD == 4

You talk as though the c4x port has never worked.  It has done in
previous releases, of course, and the way it sets up things like
BITS_PER_UNIT is exactly the way the current gcc infrastructure
expects it to.

Also, I don't think the assumption that SFmode is 32 bits is anything
like as pervasive (in the middle end) as you seem to suggest.

Admittedly, it looks like some new hard-coded uses of SImode have snuck
in with the new rtl optimisations, but any middle-end assumption along
the lines of:

      GET_MODE_BITSIZE (SImode) == 32
   or GET_MODE_BITSIZE (SFmode) == 32

is a bug.  And as per the earlier messages in the thread, my understanding
is that the right way of getting an N-bit mode is to use mode_for_size().

Note that uses of SFmode, etc., in libgcc2.[hc] don't really count.
The c4x port doesn't use those *sf routines anyway.  It would be nice
to generalise libgcc2.c so that the selection of routines is a bit
less kludgy, but that's a general comment; it doesn't just apply to
BITS_PER_UNIT != 8 considerations.

(Hmm.  I guess a lot of this just echoes Joseph's answer really.)

Richard