🚀 go-pugleaf

| gcc 2.2.2 on a decstation
| 
| The basic question is:  why does this:
| 
| 	li	$4,10000000
| 
| become this:
| 
|         lui     $4,(0x00980000)>>16     # Here's the source of my question.
|         ori     $4,$4,0x967f            # Why's it doing this instead of
| 
| when I use -O -fschedule-insns?  And, is it a bug?  (And there's one more
| teeny thing at the end about using 'slt...beq' instead of 'bne'.)

No, this is not a bug.  It takes two instructions to load 1000000
(decimal) into a register.  When you do -fschedule-insns (and
-fdelayed-branch), it will split insns that the machine says are
really several instructions into their component parts, so that each
instruction can be scheduled.  The reason you don't do the split
earlier (such as in the recognition phase), is it gives better code
generation to the higher level optimization phases to have a slightly
more general machine, than the real machine (where to draw the line is
an art).  Also, for the specific case mentioned, the backend is
required to have an insn that puts any arbitary integer constant into
a register.

As to why use 'lui' instead of the macro 'li', it was to avoid a bug
in GAS (since fixed) on the OSF/1 reference port, which did not map
li's of a number with just the upper bits set into a lui instruction.

| #
| #   This way would save us one 'slt' at each iteration, but it's
| #    hard for gcc to figure out that the loop is actually a != instead
| #    of a <.  (I wouldn't bring it up, but MIPS cc does this.)
| #	.set	noreorder
| #	.set	nomacro
| #	bne	#3,$4,$L5
| #	.set	macro
| #	.set	reorder

It's problem something to think about for loop induction.

--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.