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

[Paul Schlie]

> From: Richard Sandiford <rsandifo@redhat.com>
>> Paul Schlie <schlie@comcast.net> writes:
>> However I remain strongly skeptical about:
>> 
>> "GET_MODE_BITSIZE (QImode) == BITS_PER_UNIT"
> 
> You mean you're sceptical that that's the current definition of QImode,
> or whether it's a _good_ definition of QImode? ;)  My understanding is
> that it really is the current definition of QImode.  If you're thinking
> about a _better_ definition, well... my preference would be to remove
> all knowledge of particular modes from target-independent code.
> 
> Zack has already provided a way for targets to provide their own modes.
> If we want to change the way mode bitsizes are handled (and I'm not
> necessarily sure we do) I think the logical step is to put the
> definition of all modes under target control.  Any middle-end code
> would then be forced to use functions like mode_for_size() rather
> than use hard-coded choices like QImode, SImode, etc.
> 
> Obviously there would be a lot of commonality between BITS_PER_UNIT == 8
> targets and there would probably be a common *.def file for it.
> 
> But this sort of thing is academic unless someone's actually prepared
> to do the work (for all targets!).

Sorry if I've missed it, where is where does BITS_PER_UNIT define the root
size of all target modes? (i.e. where is a UNIT hard equated with QImode?)

I've searched all the sources, and can't find any relationship established
between BITS_PER_UNIT any mode definitions anywhere, all I found as it's use
to assure that structures and enumerations, etc. were appropriately aligned
such that they don't cross natural target "UNIT" and/or word (BITS_PER_UNIT
* UNITS_PER_WORD) boundaries, and/or used to compute BLK mode transfer sizes
etc.?

>From the best I can tell all targets and built-ins already seem to presume
size of (SImode) == (SFmode) == IEEE float == 32, etc., with the exception
of c4x? It's these presumptions which seem to force QI as being 1/4 SI mode,
not the size of QI determining SI mode's size? (And not sure what you mean
by the middle-end no longer being able to hard-code QI/SI etc. mode sizes,
as modes sizes seem to be defined indirectly by declaring types with mode
attributes which then loosely inherit that target's defined type size;
seemingly having nothing to do with BITS_PER_UNIT or UNITS_PER_WORD?)