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



Reply via email to