------- Comment #17 from vmakarov at redhat dot com 2010-09-07 18:03 ------- (In reply to comment #16) > > > I just noticed that even in the complete absence of reload inheritance, the > allocate_reload_reg routine performs free_for_value_p checks, and therefore > implicitly takes reload ordering into account. This seems to imply that even > if we'd do merge_assigned_reloads only if no inheritance has taken place, we'd > still have a problem. > > Does anybody have any idea how much merge_assigned_reloads actually > contributes > to performance on i386, in particular now that we have a bit more post-reload > optimizers that potentially clear up duplicate code of the type generated by > unmerged reloads? >
I am thinking in the same direction. merge_assign_reloads is dated by 1993. Since then it was not practically changed. I guess postreload can remove unecessary loads if it is generated without merge_assigned_reload. I've tried to compile SPEC2000 by gcc-4.4 with and without merge_assigned_reloads. I did not find any code difference. I've tried a lot of other programs with the same result. The single difference in code I found exists on this test case. So I'd remove merge_assigned_reloads at all as it became obsolete long ago. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45312 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100907180330.30353.qm...@sourceware.org
