On Fri, 10 Feb 2012 11:00:43 -0800, Richard Henderson wrote: > On 02/10/2012 08:57 AM, Paulo J. Matos wrote: >> However, there's a failure to combine looking like: (parallel [ >> (set (reg:QI 1 AL) >> (ior:QI (mem/c/i:QI (reg/f:QI 4 AP) [2 y+0 S1 A16]) >> (reg:QI 30 [ x+1 ]))) >> (clobber (reg:CC 13 CC)) >> ]) > > Why do you think that combine should create this? >
Because combine tries to combine two insns to create it and fails. it shouldn't because ior is commutative and I have a rule accepting the first operand to be a register and the second to be general operand. That would fit if combine would swap the operands to ior. > Really, I'd have expected swap_commutative_operands_p to have put things > around the other way. Me too. > That's the way that almost all cisc machines > represent their memory operands. > Agreed, but doesn't seem to be the case. > ... Although I don't see any specific test for this in the code for > commutative_operand_precedence. That's probably at least a think-o. > > I will take a look. Thanks for the pointer. Cheers, Paulo Matos > r~ -- PMatos