From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9491 invoked by alias); 23 Dec 2012 10:02:27 -0000 Received: (qmail 9480 invoked by uid 22791); 23 Dec 2012 10:02:26 -0000 X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-we0-f179.google.com (HELO mail-we0-f179.google.com) (74.125.82.179) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 23 Dec 2012 10:02:19 +0000 Received: by mail-we0-f179.google.com with SMTP id r6so2836592wey.38 for ; Sun, 23 Dec 2012 02:02:18 -0800 (PST) X-Received: by 10.194.80.71 with SMTP id p7mr31215662wjx.38.1356256938506; Sun, 23 Dec 2012 02:02:18 -0800 (PST) Received: from localhost ([2.28.234.219]) by mx.google.com with ESMTPS id bw9sm11217503wib.5.2012.12.23.02.02.16 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 23 Dec 2012 02:02:17 -0800 (PST) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Subject: [committed] Make r10k-cache-barrier-10.c more robust Date: Sun, 23 Dec 2012 10:02:00 -0000 Message-ID: <87handulw8.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2012-12/txt/msg01371.txt.bz2 The loop in this test is supposed to trigger a likely (annulled) back-branch. However, "n" is naturally in $4 on entry to the loop and naturally in $2 on the back edge. Usually the move from $4 to $2 was outside the loop, but for -funroll-loops it was at the end of the loop body, and could be safely put in the delay slot of a normal back-branch. Perhaps the move should be outside the loop even with -funroll-loops, but it's hard to say from an artifical test like this. The move in its current position is only needed after 8 calls to bar, whereas a move before the loop would always be executed. Stuff like that should be left to real benchmarks, so here I've just tweaked the test so that "n" can be naturally in $2 on both edges. Tested on mips64-linux-gnu and applied. Richard gcc/testsuite/ * gcc.target/mips/r10k-cache-barrier-10.c: Make a branch-likely instruction more likely. Index: gcc/testsuite/gcc.target/mips/r10k-cache-barrier-10.c =================================================================== --- gcc/testsuite/gcc.target/mips/r10k-cache-barrier-10.c 2012-12-23 09:14:02.000000000 +0000 +++ gcc/testsuite/gcc.target/mips/r10k-cache-barrier-10.c 2012-12-23 09:19:45.559582821 +0000 @@ -9,6 +9,12 @@ unsigned char *bar (int); NOMIPS16 void foo (unsigned char *n) { + /* n starts in $4, but will be in $2 after the call to bar. + Encourage it to be in $2 on entry to the loop as well, + by doing some computation on it beforehand (D?ADDIU $2,$4,4). + dbr_schedule should then pull the *n load (L[WD] ...,0($2)) + into the delay slot. */ + n += 4; do n = bar (*n + 1); while (n);