Could not split insn

[Dave Korn]

> -----Original Message-----
> From: Hans-Peter Nilsson [mailto:hp@bitrange.com] 
> Sent: 14 September 2004 16:42

> > > Besides, the constraint "o" seems wrong: it allows any
> > > offsettable operand, which includes stack operands, supposedly
> > > refused by nonimmediate_nonstack_operand.  You must not allow
> > > operands in a constraint that are disallowed by the predicate.
> >
> >   I know about the requirement that you must not allow 
> operands through a
> > predicate that aren't accepted by at least one constraint,
> 
> Not exactly, it's ok as long as it can be fixed-up to fit at
> least one constraint alternative.  You can say
> "nonimmediate_operand" + "ro" and a non-offsettable memory
> operand would always get successfully fixed-up to fit either "r"
> or "o", but not as early as an immediate operand, which would
> IIRC be loaded in a register *before* register allocation.
> It's likely (but I didn't check) that there are a lot of
> patterns that just use "general_operand", where e.g.
> "nonimmediate_operand" would make more sense (and supposedly
> give GCC/reload a better start).

  My thanks, to both you and Richard Sandiford who sent me an off-list
explanation; I think I've just grokked something I didn't get before, which
is that recog and reload approach the insn pattern from opposite directions:
in recog the predicate is the first and most important thing that filters
down the possibilities, and then the constraints are best to match up with
what the predicate allows, whereas in reload the constraints drive the
process, and the result chosen had better be allowed by the predicate.  Is
that a reasonable way to look at it?

> > but this reverse
> > condition I'm surprised by, and I can't see anything in 
> gccint that makes it
> > obvious to me what the consequences would be.....
> 
> I believe it'd be ICE or worse. :-)

  /me shudders at the thought that anything could be worse than an ICE!
 
> > was this just a thinko, or is
> > there actually a problem both ways round?
> 
> Quoteth the FM:
> 
> "The constraints allow you to fine-tune matching within the set
> of operands allowed by the predicate"
> 
> ...
> 
> "Thus the predicate must always recognize any objects allowed by
> the constraint."

  Ah, gotcha.  I was looking at (well, remembering) the bit just below
that....

"   If the operand's predicate can recognize registers, but the constraint
does not permit them, it can make the compiler crash.  "

and perhaps mis-extrapolating it to a more general belief that if the
predicate permitted anything that there wasn't a suitable constraint
alternative for, the same would happen.  But I see now that that's actually
a very specific consequence of the fact that reload fixes things up by
loading them into registers, and by that stage it's far too late for
anything mid-end to try and rearrange it if the insn can't accept registers.

"  When this operand happens to be a register, the reload pass will be
stymied, because it does not know how to copy a register temporarily into
memory. "

  Right; this means that it's only the mid-end that knows about things like
spilling temporaries into stack slots, I think?


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....