From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25947 invoked by alias); 31 Oct 2009 13:45:50 -0000 Received: (qmail 25939 invoked by uid 22791); 31 Oct 2009 13:45:48 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from ey-out-1920.google.com (HELO ey-out-1920.google.com) (74.125.78.145) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 31 Oct 2009 13:45:43 +0000 Received: by ey-out-1920.google.com with SMTP id 5so716762eyb.46 for ; Sat, 31 Oct 2009 06:45:40 -0700 (PDT) Received: by 10.216.85.5 with SMTP id t5mr1698893wee.142.1256996740440; Sat, 31 Oct 2009 06:45:40 -0700 (PDT) Received: from localhost (rsandifo.gotadsl.co.uk [82.133.89.107]) by mx.google.com with ESMTPS id 7sm145732eyb.0.2009.10.31.06.45.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 31 Oct 2009 06:45:39 -0700 (PDT) To: Paolo Bonzini Mail-Followup-To: Paolo Bonzini ,Richard Guenther , gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Cc: Richard Guenther , gcc-patches@gcc.gnu.org Subject: Re: RFC patch: invariant addresses too cheap References: <84fc9c000910200201j264856cfi6ac7a2360883d748@mail.gmail.com> <878werq41v.fsf@firetop.home> <84fc9c000910310414l40824315m45ff282e98e3b640@mail.gmail.com> <4AEC1C84.9050606@gnu.org> From: Richard Sandiford Date: Sat, 31 Oct 2009 13:53:00 -0000 In-Reply-To: <4AEC1C84.9050606@gnu.org> (Paolo Bonzini's message of "Sat\, 31 Oct 2009 12\:16\:20 +0100") Message-ID: <873a4zpth9.fsf@firetop.home> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-10/txt/msg01849.txt.bz2 Paolo Bonzini writes: > On 10/31/2009 12:14 PM, Richard Guenther wrote: >> On Sat, Oct 31, 2009 at 11:58 AM, Paolo Bonzini wrote: >>> On 10/31/2009 10:57 AM, Richard Sandiford wrote: >>>> >>>> So either I need to hack MIPS so that >>>> 2 is cheap and 3+ is "expensive", or we need some better way >>>> of determining this. >>> >>> - return mips_address_insns (addr, SImode, false); >>> + int insns = mips_address_insns (addr, SImode, false); >>> + return insns == 1 ? 1 : COSTS_N_INSNS (insns - 1); Ick. ;/ >>> >>> ? >>> >>>> I don't think sticking an x86-specific magic number in the >>>> middle of generic code is acceptable, regardless of how big >>>> the comment above it is. ;) >>> >>> That's why I suggested using "<= COSTS_N_INSNS (1) / 2" instead of "< 3". >>> Also ix86-specific calibration, but not so brutally. :-) >> >> But then you should document that address-cost is supposed to be >> insn-cost based. Otherwise comparing apples with oranges doesn't >> make sense, even if it might look less magic to you. > > That's true. Yeah. We'd also have to document that "half an insn" is considered cheap. And what does that really mean? Are we saying that "at most half of an insn can be given over to address calculation"? Seems a bit of a weird concept to hard-wire into the compiler. And if we did that, I think we'd also want to rewrite the x86 hook so that it does use COSTS_N_INSNS. Backends shouldn't really be assuming that COSTS_N_INSNS(1) == 4. I prefer the abstract address costs we have now, and in that situation, Michael's original suggestion of having a target-defined threshold macro seems more natural. I'm not sure why it got shot down. Richard