------- Additional Comments From amylaar at gcc dot gnu dot org 2005-03-17 16:37 ------- (In reply to comment #4) > There are both primary and secondary platforms among the AUTO_INC_DEC > targets. > So it is probably good to gain some wider test coverage about the compile- > time/run-time impact of this. E.g. testing CSIBE on ARM, or SPEC on RS6000.
I currently don't have an ARM or RS6000 platform to run benchmarks on. We are looking into setting up a powermac for this task, though. AFAICS RS6000 provides register+offset addressing for all modes except the altivec vector modes, so to see any significant benefit from optimize_related_values, the benchmark should have multiple altivec memory accesses from the same structure / array in a single basic block. > One of the common complaints of RTL code is that monolithic files containing > multiple optimization passes (with interwinded functions) and with > undocumented > public interface is a maintenance mess. Compare that with tree-ssa where each > pass lives in its own small[1] file and just exposes the pass description > structure. > > I believe it would be great if the new pass could be live in its own file. > The > utility functions currently in regmove could be extracted in regmovelib or > whatever name fits best. I am willing to make that change, but would first like to hear from a global or middle-end maintainer that they agree that this is a move in the right direction. Also, there are some details that should be agreed on first. I.e.: Should tehre remain a toplevel regmove function that calls mark_flags_life_zones first, and then the sub-passes, or should each sub-pass call mark_flags_life_zones? If there is such a toplevel functiojn, would it live in the regmove* files, or would that be rest_of_handle_regmove in passes.c ? Where does the combine_stack_adjustments pass belong? Should it be in flow.c, or in it's own file (combine_stack_adj.c ?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
