From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9834 invoked by alias); 3 Dec 2009 12:56:37 -0000 Received: (qmail 9757 invoked by uid 22791); 3 Dec 2009 12:56:36 -0000 X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Dec 2009 12:56:27 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id 624FE890B6; Thu, 3 Dec 2009 13:56:24 +0100 (CET) Date: Thu, 03 Dec 2009 12:57:00 -0000 From: Michael Matz To: Richard Sandiford Cc: Paolo Bonzini , Richard Guenther , gcc-patches@gcc.gnu.org Subject: Re: RFC patch: invariant addresses too cheap In-Reply-To: <87pr6xrp6h.fsf@firetop.home> Message-ID: References: <878werq41v.fsf@firetop.home> <84fc9c000910310414l40824315m45ff282e98e3b640@mail.gmail.com> <4AEC1C84.9050606@gnu.org> <873a4zpth9.fsf@firetop.home> <4AEC48FF.7000808@gnu.org> <871vkiy24o.fsf@firetop.home> <874ooxmkf8.fsf@firetop.home> <87skcfirlx.fsf@firetop.home> <87einjaski.fsf@firetop.home> <87pr6xrp6h.fsf@firetop.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: 2009-12/txt/msg00186.txt.bz2 Hi, On Wed, 2 Dec 2009, Richard Sandiford wrote: > > Having said that, I'm not sure why the answer to this question matters > > to you: neither the PR33928 testcase, nor 410.bwaves was about (reg,reg,4) > > vs. ofs(reg,reg,4). The former was about ofs(reg) vs ofs2(reg) and the > > latter was about (reg) vs (reg,reg). > > Well, the point was that if fwprop2 is allowed to make the substitution, > it would solve both of the problems you list. And that seems like > conceptually the right fix. But as Paolo says, allowing fwprop2 to make > the substitution would regress PR30907, because of the costs issue above. Ah, that was what the ofs(reg,reg,4) was about. Yeah, according to the optimization guide this shouldn't be slower on K8 or K10, but well, reality trumps paper :) > But fwprop.c compares "before" and "after" costs, and I was thinking it > should do the same in this case too (if allowed to). No absolute cost > checks should be needed. Oh, right, of course. > (a) fwprop could once again propagate invariants into loops and > (b) when it did so, it could ask for a stricter cost, so that we don't > inadvertently replace one loop instruction with a more expensive > loop instruction (as we did in 30907). ... > But it might be nice to have a separate mode that's > suitable for forward-propagating values into blocks of higher frequency, > along the lines of (b). Does that sound reasonable? IMO yes. > [ Having said that, although I could try to write a patch along > those lines, I'm not sure I could test it very well. ;( I don't > have access to things like SPEC. ] We could test SPEC test patches, but we don't have Nullstone anymore. Ciao, Michael.