http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-05-04 14:21:28 UTC --- The problem is the MEMs nested in other MEM addresses, cselib isn't prepared to handle it efficiently. So, either we should break very deep MEM nests using extra DEBUG_INSNs and debug temporaries (not sure how easy it would be to break them during expand_debug_expr, so perhaps either when expand_debug_expr finishes, or perhaps during vt_initialize before an insn is passed to cselib_process_insn), or cselib would need to have some cache on MEMs it already looked up during current toplevel cselib_lookup or cselib_subst_to_values calls - for small number of MEMs perhaps a linear cache that cselib_lookup_mem could iterate over, holding MEM rtx / corresponding cselib_val * pairs, for bigger amounts perhaps pointer_map. Without such a cache, 14 nested MEMs result in certainly more than 4 billion cselib_lookup searches within one cselib_process_insn.
