From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28407 invoked by alias); 21 Aug 2007 12:11:13 -0000 Received: (qmail 28330 invoked by uid 22791); 21 Aug 2007 12:11:12 -0000 X-Spam-Check-By: sourceware.org Received: from dmz.mips-uk.com (HELO dmz.mips-uk.com) (194.74.144.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Aug 2007 12:11:04 +0000 Received: from internal-mx1 ([192.168.192.240] helo=ukservices1.mips.com) by dmz.mips-uk.com with esmtp (Exim 3.35 #1 (Debian)) id 1INSZY-0001fW-00; Tue, 21 Aug 2007 13:11:00 +0100 Received: from southgate.mips.com ([192.168.192.171]) by ukservices1.mips.com with esmtp (Exim 3.36 #1 (Debian)) id 1INSZQ-00076C-00; Tue, 21 Aug 2007 13:10:52 +0100 Message-ID: <46CAD64C.9050108@mips.com> Date: Tue, 21 Aug 2007 12:14:00 -0000 From: Nigel Stephens User-Agent: IceDove 1.5.0.12 (X11/20070606) MIME-Version: 1.0 To: Nigel Stephens , Sandra Loosemore , GCC Patches , Guy Morrogh , David Ung , Thiemo Seufer , Mark Mitchell , richard@codesourcery.com Subject: Re: PATCH: fine-tuning for can_store_by_pieces References: <46C3343A.5080407@codesourcery.com> <87ps1nop2x.fsf@firetop.home> <46C778D6.5060808@codesourcery.com> <87y7g6r50c.fsf@firetop.home> <46CA222D.2050107@codesourcery.com> <87ps1h5mda.fsf@firetop.home> <46CABE2A.2090406@mips.com> <873ayd5d3g.fsf@firetop.home> In-Reply-To: <873ayd5d3g.fsf@firetop.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MIPS-Technologies-UK-MailScanner: Found to be clean X-MIPS-Technologies-UK-MailScanner-From: nigel@mips.com 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: 2007-08/txt/msg01351.txt.bz2 Richard Sandiford wrote: > Nigel Stephens writes: > >> Richard Sandiford wrote: >> >>> Sandra Loosemore writes: >>> >>> >>>> OK, but what I was really asking was, is there a way to *test* for >>>> situations where we should generate the lui/ori/sw sequences instead >>>> of the lw/sw? Some combination of TARGET_foo flags and/or the size of >>>> the string? >>>> >>>> >>> Well, I suppose: >>> >>> !optimize_size && !TARGET_MIPS16 && mips_issue_rate () > 1 >>> >> Many MIPS dual-issue processors are asymettric, and may be able to issue >> lui, ori and sw down only one pipe or the other -- not both in parallel. >> So I don't think that testing mips_issue_rate() is sufficient. >> > > True. I suppose I'm biased because all the processors whose schedulers > I've worked on could issue stores down one pipe and arithmetic > instructions down the other. > > Your assumption is probably correct, however your schedule for the first two cycles shows two lui and two ori issuing in parallel, which would not be possible in such an architecture. For a long enough string though it could be a win. > I assume you think we should stick the uncoditional zero here? > We could make the STORE_BY_PIECES_P macro dependent on -mtune, and use the size and alignment to estimate the total cycle count. But zero is reasonable and we could add a comment suggesting that there's some opportunity for future tuning on muilti-issue cpus. Nigel