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: Tue, 12 Dec 2006 16:07:33 +0100 (CET)
- Subject: Re: [PATCH] Fix PR middle-end/28690, indexed load/store performance + reload bug
- References: <200612111933.kBBJXsqr028103@d12av02.megacenter.de.ibm.com>
On Mon, 11 Dec 2006, Ulrich Weigand wrote:
> > registers acceptable in all operands (which would be the
> > intersection), but a superset. The alternate class is the biggest
> > class containing only registers which are cheaper than memory. If
> > guess on PPC all registers are cheaper than MEMs, so that's ALL_REGS
> > for all alternate classes then.
> Hmm. I would have expected regclass to ensure its selection results in
> instructions that are at least valid in the non-strict sense (i.e.
> satisfy the predicates).
Well, regclass can't look at the predicates, so how should it do that?
Predicates can be arbitrary functions (they don't even have to be pure or
const), so in general you can not say which operands they will accept
before actually putting them into the instruction at hand, and trying to
The only information there is for regclass is the constraints and they are
only taken as hint in regclass, not as something which needs to be
fullfilled strictly (of course not, because with conflicting constraints
in different insns for the same operand you would end up with the empty
regclass, i.e. memory, where normally it's better to just create one or
two reloads in the non-matching insn).
> If this is not the case, then I guess the question becomes what is the
> point of rejecting particular registers in predicate in the first place?
> Does this make sense at all then?
Tough question. From a documentation and debugability p.o.v. it makes
sense IMO, as the predicate will reject an insn as soon as it get's the
wrong register. And if the expanders do the right thing (e.g. creating a
hard-reg right from creating the insn) that would point to a problem in
some optimizer, so in a way rejecting insns earlier than after reload (via
predicates) might be good.
They will also serve code quality sometimes, but only when no pseudo regs
are accepted (and hence generated in the beginning), as then we can be
sure to require no reloads later. This is not the case here, though.
But in general predicates should only be used to guide the structural form
of operands, not the specific instance.
With structural form I mean things like
(unspec (MEM (REG X)) 42)
(MEM (PLUS (REG X) (REG Y)))
and so on, including properties inferable from modes or sizes and the
like, and an instance would set all free variables to specific
values. Free variables would in general be all "numbers". For register
numbers predicates can do a bit more than just accepting all registers,
they can restrict themself to accepting only a subset. But then this
subset in general needs to be backed by a register class (or reg class
union). So I would also include "register classes" into properties of
structural form. The natural example would be accepting float regs but
not integer ones in the predicate. But _individual_ register numbers not
connected to any particular class are a property not of form but of
specific instance of the operand.
The above restriction (to only apply to structure) then also means that
regclass can't infer much usefull information from predicates.