From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11216 invoked by alias); 11 Mar 2013 18:17:48 -0000 Received: (qmail 11116 invoked by uid 22791); 11 Mar 2013 18:17:43 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_FW X-Spam-Check-By: sourceware.org Received: from mail-vb0-f53.google.com (HELO mail-vb0-f53.google.com) (209.85.212.53) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Mar 2013 18:17:29 +0000 Received: by mail-vb0-f53.google.com with SMTP id fj18so1772093vbb.26 for ; Mon, 11 Mar 2013 11:17:27 -0700 (PDT) X-Received: by 10.220.153.143 with SMTP id k15mr5066845vcw.33.1363025847770; Mon, 11 Mar 2013 11:17:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.237.1 with HTTP; Mon, 11 Mar 2013 11:16:47 -0700 (PDT) In-Reply-To: <513E1E13.40403@redhat.com> References: <513E1E13.40403@redhat.com> From: Steven Bosscher Date: Mon, 11 Mar 2013 18:17:00 -0000 Message-ID: Subject: Re: extend fwprop optimization To: Jeff Law Cc: Wei Mi , GCC Patches , David Li , Uros Bizjak Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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: 2013-03/txt/msg00413.txt.bz2 On Mon, Mar 11, 2013 at 7:10 PM, Jeff Law wrote: > On 03/10/2013 11:52 PM, Wei Mi wrote: >> >> Hi, >> >> This is the fwprop extension patch which is put in order. Regression >> test and bootstrap pass. Please help to review its rationality. The >> following is a brief description what I have done in the patch. >> >> In order to make fwprop more effective in rtl optimization, we extend >> it to handle general expressions instead of the three cases listed in >> the head comment in fwprop.c. The major changes include a) We need to >> check propagation correctness for src exprs of def which contain mem >> references. Previous fwprop for the three cases above doesn't have the >> problem. b) We need a better cost model because the benefit is usually >> not so apparent as the three cases above. >> >> For a general fwprop problem, there are two possible sources where >> benefit comes from. The frist is the new use insn after propagation >> and simplification may have lower cost than itself before propagation, >> or propagation may create a new insn, that could be splitted or >> peephole optimized later and get a lower cost. The second is that if >> all the uses are replaced with the src of the def insn, the def insn >> could be deleted. >> >> So instead of check each def-use pair independently, we use DU chain >> to track all the uses for a def. For each def-use pair, we attempt the >> propagation, record the change candidate in changes[] array, but we >> wait to confirm the changes until all the pairs with the same def are >> iterated. The changes confirmation is done in the func >> confirm_change_group_by_cost. We only do this for fwprop. For >> fwprop_addr, the benefit of each change is ensured by >> propagation_rtx_1 using should_replace_address, so we just confirm all >> the changes without checking benefit again. > > Can you please attach this to the 4.9 pending patches tracker bug. We're > really focused on trying to get 4.8 out the door and this doesn't seem like > suitable material for GCC 4.8. > > I haven't looked at the details of the patch at all yet and doubt I would > prior to GCC 4.8 going out the door. > > Thanks, > jeff > Jeff, The world has more people than you, and with different interests. This patch was posted here for comments on the idea, and while I'm sure your feedback would be very valuable, it is no more required for discussing this patch than it is for releasing GCC 4.8. Ciao! Steven