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

[Michael Matz]

Hi,

On Fri, 8 Dec 2006, Ulrich Weigand wrote:

> > The constraints in that instruction seem to not forbid reg 65.  Hence 
> > global (in fact regclass.c) has no reason to believe that it can not 
> > be used for that operand (the register allocator is driven only by the 
> > constraints as far as register classes are concerned).  The predicate 
> > must not reject registers which the constraints accept.  If for some 
> > reason you need to reject some hardregs already in the predicate then 
> > you need to create a new register class which also excludes that 
> > register and use that in the constraints.
> 
> 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 ...

Oh, indeed.  I simply assumed it would as otherwise global shouldn't 
allocate that one :-/  

> Any idea why global/regclass might not respect that?

No.  Indeed in Peters dumps regclass uses GENERAL_REGS as preferred class 
for pseudo 238 (with no alternate class).  One thing is special about it: 
it's an uninitialized register.  That could change the conflicts, but 
shouldn't change the permissible hardregs for it, but perhaps it's 
coalesced with some other reg which allows LINK_REG?  Only way to find out 
is to breakpoint in global.c:find_reg until REGNO(allocno[num.reg) is 238 
and see why it chooses 65.  I don't really see where it could broaden to 
more than "reg_preferred_class (allocno[num].reg)" as the 'used[12]' 
bitmaps contain at least the complement of that class (so both should 
contain reg 65), and before chosing a register it's checked if it's in 
'used'.  Even the recursive call when it tries to use caller saved regs 
should have this property.


Ciao,
Michael.