Could not split insn

[Hans-Peter Nilsson]

On Tue, 14 Sep 2004, Dave Korn wrote:
> > -----Original Message-----
> > From: gcc-owner On Behalf Of Hans-Peter Nilsson
> > Sent: 14 September 2004 02:34
>
> > 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).

> 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. :-)

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

brgds, H-P