On 17 May 2006 19:48, Andreas Krebbel wrote:
>> Doesn't this mean that your insn patterns should be using numerical (aka
>> "matching") constraints?
>
> Oh we are using matching constraints. But of course nobody except reload
> does care about them. If the only constraints for an operand are matching
> constraints
> you can use match_dup what would be honored by validate_canon_reg. But we
> have 3 operand ANDs for registers and 2 operand ANDs for memory operands.
> To give reload full choice we have put them together in one pattern.
> For the memory variants we are using matching constraints and use the
> insn condition to make sure that the MEMs on both sides match.
Hmm. I note that if you /were/ using match_dups, the problem would be
solved because all four changes would go through the 'then' clause of the
if...else construct. Maybe it would be more worthwhile for you to have
separate patterns after all and find some other way of making reload happy.
> Btw. this is not a s390 back end invention. You can see the same in the
> i386.md file for "anddi3".
Eh? I've looked at 3.3.3 and at HEAD and it seems to be doing everything
completely differently: there are no constraints at all, let alone matching
ones, the pattern in question is an expander not an insn pattern, and the
expander routine ix86_expand_binary_operator takes care of making sure only
valid combinations of mem operands are used.
>> After all, what CSE has done is valid in general
>> given that rD contains the same value as rB; if it's a requirement of the
>> s390 backend that all mem operands in a single instruction are identical,
>> it should specify so in the .md file, or it should offer expanders for
>> mem->mem operations so that reload can deal with them.
>
> I'm not that sure that the changes done by cse are valid. Usually changing
> rtxs should always be followed by a call to recog. Yes I know there are
> exceptions like regrename but they are coming with workarounds like leaving
> the constraint string empty to protect the insn which I don't see here at
> the moment.
Well, hang on. The change that you're complaining of is replacing one
pseudo by another. It's fairly fundamental that gcc assumes that all pseudos
are equivalent and freely interchangeable; there are no reg classes in
pseudos. So if your design places special restrictions on gcc's use of and
freedom to swap and substitute pseudos, your design is probably making an
invalid assumption about gcc's use of pseudos, or it's trying to do something
by placing constraints on pseudo-reg numbers that it should be trying to do by
some other means.
cheers,
DaveK
--
Can't think of a witty .sigline today....
