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

[Michael Matz <matz at suse dot de>]

Hi,

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 
recog.

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
  (const_int X)
  (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.


Ciao,
Michael.