[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 at gcc dot gnu dot org>]

------- Comment #12 from mkuvyrkov at gcc dot gnu dot org  2009-06-23 17:21 -------
(In reply to comment #11)
> Still, I don't think a target hook is the solution.  Even if it adds hack over
> hack, having the "funny precedence" rules only before reload could be a
> solution.

For the record, I consider the hook to be a feature, the one which backends can
use to tweak code generation, not a hack.  At the moment, the precedence which
favors pointers is a hack, but we cannot remove it due to powerpc being a
important platform.  Also, favoring the pointers may be useful for other
similar to ppc platforms even if we are not aware of them right now.

That said, conditioning the precedence on (!reload_in_progress &&
!reload_completed) fixes the bug so I consider this to be the second best thing
to a hook.

It is not as good as a hook because there may be corner cases during reload
when pointers should be favored on powerpc (multi-dimension array references,
probably).  On the other hand m68k need unrestricted (in the sense that all
RTX_OBJ are the same) commutativeness during reload to avoid ICEs.

So, conditioning pointer precedence on reload_in_progress has possible
performance degradation on powerpc on one hand and ICE on m68k on the other.

> I'm pretty sure that we are talking about two different things. :-)

Err, I don't fully follow you here.  What are the two different things?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37053