From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24196 invoked by alias); 17 Mar 2005 16:38:05 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 23892 invoked by uid 48); 17 Mar 2005 16:37:41 -0000 Date: Thu, 17 Mar 2005 16:38:00 -0000 Message-ID: <20050317163741.23891.qmail@sourceware.org> From: "amylaar at gcc dot gnu dot org" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050225161912.20211.amylaar@gcc.gnu.org> References: <20050225161912.20211.amylaar@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug rtl-optimization/20211] autoincrement generation is poor X-Bugzilla-Reason: CC X-SW-Source: 2005-03/txt/msg02121.txt.bz2 List-Id: ------- 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