Re: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug

[Michael Matz <matz at suse dot de>]

Hi,

On Fri, 8 Dec 2006, Peter Bergner wrote:

> > That's what I thought at first, but operand 0 in *addsi3_internal has 
> > only 'r' as constraint, which should be interpreted as GENERAL_REGS, 
> > and that class does not contain reg 65 ...
> > 
> > Any idea why global/regclass might not respect that?
> 
> It seems that this is normal.

Bummer.  I still don't understand why find_reg could chose register 65 
although it's not in the register class contents for pseudo 238, patched 
or unpatched compiler.  

> exactly the same rtl insn (below) passed into eliminate_regs_in_insn as we
> do with the patched compiler.  The difference is that the unpatched compiler
> doesn't attempt to call recog on the insn and doesn't have an gcc_assert.

Hmm, I seem to be confused, but which patch are you refering to now?  I 
don't see any which adds a recog() call.

> With the unpatched compiler, looking in the rtl dumps (which I've made
> available at http://www.bergner.org/gcc/reload-base/ ), we can see that
> sometime after the call to eliminate_regs_in_insn, insn 139 is split into
> the insns below (I've included the relevant portions of the glocal-alloc
> rtl dump.

Ah, that's now reload doing the right thing (the insn isn't split, but an 
output reload is created).

> So I'm guessing, we need to just let this insn pass by without trying to 
> call recog() on it?

If that's the problem, then the predicate (the one rejecting special 
registers) needs testing for reload_in_progress.  Only when that is set 
should we see temporarily invalid instructions with reg 65 in "r" operands 
(although I still find that curious to have at all).


Ciao,
Michael.