Hi Dave, thanks for your comments.
> 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. Btw. this is not a s390 back end invention. You can see the same in the i386.md file for "anddi3". > 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. > Then again, I don't quite understand your question, because as far as I can > see that's not a mem on the RHS, that's an and operation between a mem and an > immediate; can you clarify showing before and after RTL, and the relevant md > patterns? Not on this system but I could send the rtl pieces tomorrow. Bye, -Andreas-
