🚀 go-pugleaf

michael@stb.INfo.COM (Michael Gersten) writes:
>Here's a question on emit_move_insn.

>If the mode is the same size as UNITS_PER_WORD, then it goes into this
>routine,  which ends with another emit_move_insn call.
>
>On my system this is giving an infinite loop. Since it's still there, and
>no one  else has complained, I'm assuming it's something else that is
>triggering this.

It looks like a bug to me, but the reason why no one else has complained
is that all standard machine descriptions provide instructions
for multiple word move instructions, so this section of the code
is never used.  Like the comment there says, much better code is
generated if you provide the patterns, and don't split the move.

>From tm.h:

>#define BITS_PER_UNIT 16
>#define BITS_PER_WORD 16
>#define UNITS_PER_WORD 1

GNU C doesn't seem to really support values of other than 8, 32, 4
respectively for these definitions.  Using different values is likely to
lead to more than a few supprises.  I'd consider editing machmode.def.
Normally with the above definitions you'ld get integer modes like this:

	Mode    words bits  C type
	QImode	  1    16   char, short
	HImode	  2    32   int, long
	SImode	  4    64   long long
	DImode	  8   128
	TImode   16   256

I'd change it so you'ld get modes like this:

	Mode    words bits  C type
	QImode	  0     0
	HImode	  0     0
	SImode	  1    16   char, short
	DImode	  2    32   int, long
	TImode    4    64   long long

This reflects that a "single integer" on your machine is really only
16 bits wide, and a "double integer", which requires two regisiters
to hold, is 32 bits wide.  This is more in line with the modes GCC
uses on the 32 bit word, 8 bit byte machines it desgined for.
You will run into a few places where GCC assumes that QImode 
has some meaning, but this isn't really a problem.

							Ross Ridge