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

[Paul Schlie <schlie at comcast dot net>]

> From: "Joseph S. Myers" <joseph@codesourcery.com>
>> From the best I can tell all targets and built-ins already seem to presume
> 
> Target code can naturally assume the mode sizes used for that target.
> 
>> size of (SImode) == (SFmode) == IEEE float == 32, etc., with the exception
> 
> The middle-end does need to have a mode to access individual bytes; that
> is QImode.  Every other hardcoded reference to a particular mode is a bug
> except for special cases such as handling __attribute__((mode)), which
> need conditioning on whether the mode exists for the particular target.
> 
> The floating-point modes are target-specific; SFmode and DFmode merely
> have convenient default definitions.  You'll note that the middle-end
> contains no references (in code as opposed to comments) to either SFmode
> or DFmode (reg-stack.c being target code that happens to be outside
> config/, so references there are OK).  The aim should be to end up in a
> similar situation with regard to SImode: it's a target-specific mode which
> most but not necessarily all targets define, most of them as 32-bit.  You
> may not have noticed that people have attempted ports (although not added
> them to FSF GCC) to systems with 64-bit bytes where no 32-bit mode is
> meaningful at all, whatever you might wish to call it.

Thank you. It appeared that regardless of the documentation, that since
arbitrarily sized BLK moves/cmp/clear's seemed to be the only "code"
generated by GCC that dealt specifically with byte data, that all remaining
operations would specify objects consistent with the target's specification,
as the program can only specify operations on such data types. Thereby
apparently enabling the specification of a target without QI mode support,
which just happed to seem like an potentially more ideal approach to enable
similarly sized objects on different targets to utilize the same mode by
default, rather than needing to define QI mode as the smallest supported
data type regardless of it's size. Sorry for the noise and distraction.