This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Mon, 4 Apr 2005, Paul Schlie wrote:

> 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?)

In the specification of the modes, i.e. in rtl.texi.  You need to read the 
internals manual before posting further on this matter to avoid wasting 
everyone's time with misunderstandings of matters it specifies.

	Here is a table of machine modes.  The term ``byte'' below refers to an
	object of @code{BITS_PER_UNIT} bits (@pxref{Storage Layout}).

	[...]
	@findex QImode
	@item QImode
	``Quarter-Integer'' mode represents a single byte treated as an integer.

> 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.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]