------- Comment #8 from mkuvyrkov at gcc dot gnu dot org 2009-06-23 11:39 ------- (In reply to comment #6) > But that was the meat of fixing PR28690. :-( > > The insn should satisfy the constraints of alternative 4.
Well, not really. For the insn to match alternative 4 the pattern should be non-canonical. The last sentence in GCC Internals' canonicalization rules says: "Further canonicalization rules are defined in the function commutative_operand_ precedence in gcc/rtlanal.c" Unfortunately, commutative_operand_precendence() at the moment clearly states that a pointer (being that a MEM or a REG) has precedence over other RTX_OBJs. It is absolutely unclear to me why a pointer should have precedence over, say, multiplication or anything else (and "yes", I've read PR28690). With my target-independent hat on, I would remove that PPC-specific hunk from commutative_operand_precendence() or, if that is really that important to PPC, add a new target hook so that different targets can enjoy privilege of defining that to whatever they seem fit. Adding such an obscure canonicalization rule for all targets seems unjustified. I'd like to get some feedback on the above before I start implementing new target hook to make all targets happy. Peter, I'm CCing you as the author of the commutative_operand_precendence() piece to get your opinion on the above. -- mkuvyrkov at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mkuvyrkov at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053