This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug
- From: Michael Matz <matz at suse dot de>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Peter Bergner <bergner at vnet dot ibm dot com>, Andrew Pinski <pinskia at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 8 Dec 2006 18:47:06 +0100 (CET)
- Subject: Re: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug
- References: <200612081715.kB8HFEQd028351@d12av02.megacenter.de.ibm.com>
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'
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.