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

[Paul Schlie <schlie at comcast dot net>]

> From: Richard Sandiford <rsandifo@redhat.com>
>> Unfortunaly all I see is a definition of their relative sizes,
> 
> Are we looking at the same sources?
> 
> 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

  CHAR_TYPE_SIZE == 32   (SI mode, thereby QI/HI emulation not needed)
  SHORT_TYPE_SIZE == 32  (SI mode, ...)
  INT_TYPE_SIZE == 32    (SI mode)
  LONG_TYPE_SIZE == 32   (SI mode)
  FLOAT_TYPE_SIZE == 32  (SF mode, thereby consistent with SI/SF/float)
  DOUBLE_TYPE_SIZE == 32 (SF mode, ...)

  (which would seem to be fine, as otherwise GCC wouldn't be sizing
   it's operations consistent with the target's defined type sizes;
   which in this instance are all 4-byte SI/SF mode operations, therefore
   would never need to access any operand other then it's native 4-byte
   word size except for bit-fields, which will always also be contained
   within an SI mode operands, although possibly aligned on or packed
   across 8-bit boundaries but within the SI mode word.)

  Does that seem like it would work?