From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4445 invoked by alias); 6 Sep 2005 13:00:10 -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 4391 invoked by uid 48); 6 Sep 2005 13:00:05 -0000 Date: Tue, 06 Sep 2005 13:00:00 -0000 Message-ID: <20050906130005.4388.qmail@sourceware.org> From: "bjoern dot m dot haase at web dot de" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050904220013.23726.bjoern.m.haase@web.de> References: <20050904220013.23726.bjoern.m.haase@web.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug rtl-optimization/23726] Missed optimizations for divmod X-Bugzilla-Reason: CC X-SW-Source: 2005-09/txt/msg00662.txt.bz2 List-Id: ------- Additional Comments From bjoern dot m dot haase at web dot de 2005-09-06 12:59 ------- I have done some code reading now and come to the following conclusion: When having an expanded sequence that provides one single result, libcall blocks are an appropriate method for making sure that a single-set insn that carries a REG_EQUAL note is *not* deleted too early. Libcall notes, however, do not provide a method so far for dealing with library calls or expanded sequences that yield *two* results. E.g. they are no solution for both, divmod4 on the one hand and arithmetic expanders doing subreg lowering and also yielding a CC on the other hand. In order to keep changes as small as possible, my suggestion is to change static void rest_of_handle_jump2 (void) such that it no longer calls "delete_trivially_dead_insns ()" at it's very beginning. (I'd have posted a patch, if savannah.gnu.org is down right now.) IIUC that the trivially dead insn are in first line a performance issue because they need memory and handling that would otherwise not be necessary, my suggested change would not be too serious. "delete_trivially_dead_insns ()" would be among the first things that is called in the pass that immediately follows jump2: The first cse pass. I'd appreciate comments on whether such trivially dead insn could prevent jump2 from realizing important optimization steps. Bjoern. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23726