From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10245 invoked by alias); 16 Jul 2010 19:55:31 -0000 Received: (qmail 10235 invoked by uid 22791); 16 Jul 2010 19:55:30 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,TW_FW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Jul 2010 19:55:23 +0000 Received: (qmail 17999 invoked from network); 16 Jul 2010 19:55:21 -0000 Received: from unknown (HELO ?84.152.205.171?) (bernds@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Jul 2010 19:55:21 -0000 Message-ID: <4C40B910.7070502@codesourcery.com> Date: Fri, 16 Jul 2010 19:55:00 -0000 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100625 Thunderbird/3.0.5 MIME-Version: 1.0 To: Paolo Bonzini CC: GCC Patches Subject: Re: New optimization for reload_combine References: <4C4035C3.9080305@codesourcery.com> <4C40B6E3.8000908@gnu.org> In-Reply-To: <4C40B6E3.8000908@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-07/txt/msg01383.txt.bz2 On 07/16/2010 09:45 PM, Paolo Bonzini wrote: > On 07/16/2010 12:34 PM, Bernd Schmidt wrote: >> This can make the generated code quite a lot nicer: >> >> - adds r3, r2, #2 >> strb r5, [r2, #0] >> - strb r5, [r3, #0] >> - adds r3, r2, #3 >> + strb r5, [r2, #2] >> strb r5, [r2, #1] >> - strb r5, [r3, #0] >> - adds r3, r2, #4 >> + strb r5, [r2, #3] >> lsrs r1, r1, #11 >> - strb r5, [r3, #0] >> - adds r3, r2, #5 >> + strb r5, [r2, #4] >> add r1, r1, r1, lsl #1 >> - strb r5, [r3, #0] >> + strb r5, [r2, #5] > > Nice. :) I suppose fwprop doesn't do it because the memory accesses are > not present before reload? I haven't checked, but I guess in many cases (i.e. anything stack-relative) that's the case. Also, some of the adds are produced by reload_cse_move2add. > Can you make the change dependent on > > bool speed = optimize_bb_for_speed_p (BLOCK_FOR_INSN (insn)); > > /* Prefer the new address if it is less expensive. */ > gain = (address_cost (old_rtx, mode, as, speed) > - address_cost (new_rtx, mode, as, speed)); > > /* If the addresses have equivalent cost, prefer the new address > if it has the highest `rtx_cost'. That has the potential of > eliminating the most insns without additional costs, and it > is the same that cse.c used to do. */ > if (gain == 0) > gain = rtx_cost (new_rtx, SET, speed) - rtx_cost (old_rtx, SET, speed); > > return (gain > 0); > > as in fwprop (in turn taken from CSE)? I guess I can use address_cost instead of rtx_cost. I'll make the change if it still gives me good results. The extra rtx_cost check you quoted doesn't seem worthwhile here, as the goal mentioned in the comment (i.e, eliminating the add) is achievable only if we do the replacement every time. As a followup, it would be nice to compute all the costs before replacing anything, and taking into account whether the add is dead. Bernd