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