Register Allocation issues with microblaze-elf

[Michael Eager]

Hi --

I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.

One test case that I have has a long series of nested if's
each with the same comparison and similar computation.

         if (n<max_no){
           n+=*(cp-*p++);
           if (n<max_no){
             n+=*(cp-*p);
               if (n<max_no){
		. . .          ~20 levels of nesting
	           <more computations with 'cp' and 'p'>
                 . . . }}}

Gcc-4.6.2 generates many blocks like the following:
	lwi	r28,r1,68	-- load into dead reg
	lwi	r31,r1,140	-- load p from stack
	lbui	r28,r31,0
	rsubk	r31,r28,r19
	lbui	r31,r31,0
	addk	r29,r29,r31
	swi	r31,r1,308
	lwi	r31,r1,428	-- load of max_no from stack
	cmp	r28,r31,r29	-- n in r29
	bgeid	r28,$L46

gcc-4.1.2 generates the following:
	lbui	r3,r26,3
	rsubk	r3,r3,r19
	lbui	r3,r3,0
	addk	r30,r30,r3
	swi	r3,r1,80
	cmp	r18,r9,r30	-- max_no in r9, n in r30
	bgei	r18,$L6

gcc-4.6.2 (and gcc-head) load max_no from the stack in each block.
There also are extra loads into r28 (which is not used) and r31 at
the start of each block.  Only r28, r29, and r31 are used.

I'm having a hard time telling what is happening or why.  The
IRA dump has this line:
    Ignoring reg 772, has equiv memory
where pseudo 772 is loaded with max_no early in the function.

The reload dump has
Reloads for insn # 254
Reload 0: reload_in (SI) = (reg/v:SI 722 [ max_no ])
	GR_REGS, RELOAD_FOR_INPUT (opnum = 1)
	reload_in_reg: (reg/v:SI 722 [ max_no ])
	reload_reg_rtx: (reg:SI 31 r31)
and similar for each of the other insns using 722.

This is followed by
   Spilling for insn 254.
   Using reg 31 for reload 0
for each insn using pseudo 722.

Any idea what is going on?

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s.c
Type: text/x-csrc
Size: 8068 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20130213/84542689/attachment.bin>