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