[Bug middle-end/37053] [4.3/4.4/4.5 regression] ICE in reload_cse_simplify_operands, at postreload.c:395

["mkuvyrkov at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1747 bytes --]



------- 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