[Bug rtl-optimization/20211] autoincrement generation is poor

["amylaar at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

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