Ayonam Ray <ayonam@xxxxxxxxx> writes: > On 22 May 2012 19:18, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: >> >> I'm really guessing here, but it sounds like you have an insn with an >> operand that uses an m constraint but for which the operand predicate >> accepts operands that do not meet that constraint. In general for every >> RTL that the operand predicate accepts you must have a constraint that >> can match that operand. Based on your description even general_operand >> ought to reject the symbolicRef address. >> >> Ian > > Thanks Ian, > > It is exactly as you said. I fixed my predicate for that instruction. > So what was earlier a general_operand now checks for general_operand > and in addition, it checks for the operand to be a MEM (PLUS (MULT > (REG CONST_INT)) SYMBOL_REF) and rejects those operands. I'm not sure I understand this, because it sounds like that MEM is already invalid and therefore not a general_operand. When general_operand sees a MEM, it checks that the address satisfies the legitimate_address_p target hook, and I thought you indicated that such an address would fail that hook. > However, I still get the same problem. What I noticed is that the > address conversion from using a REG instead of a SYMBOL_REF happens at > the IRA stage. I presume it is having register pressure and since the > register that contains the SYMBOL_REF is used only for these kind of > addresses, it knocks off the REG and replaces it with the SYMBOL_REF > itself. But the problem is how to make it not do so. Does it check > the instruction predicates when it does this transformation in the > IRA? I feel it doesn't. It just looks at the REG_EQUIV and REG_EQUAL > expression lists and carries out the transformation based on that. That is what it does for the transformation, yes, but it only commits the transformation back to the RTL if it is valid. At least that is how it is supposed to work. Ian
