From patchwork Thu Jul 1 18:41:34 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Fang, Changpeng" X-Patchwork-Id: 57567 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 873261007D2 for ; Fri, 2 Jul 2010 04:42:10 +1000 (EST) Received: (qmail 15849 invoked by alias); 1 Jul 2010 18:42:08 -0000 Received: (qmail 15838 invoked by uid 22791); 1 Jul 2010 18:42:07 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from va3ehsobe004.messaging.microsoft.com (HELO VA3EHSOBE004.bigfish.com) (216.32.180.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 01 Jul 2010 18:42:01 +0000 Received: from mail145-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 8.1.340.0; Thu, 1 Jul 2010 18:41:55 +0000 Received: from mail145-va3 (localhost.localdomain [127.0.0.1]) by mail145-va3-R.bigfish.com (Postfix) with ESMTP id 9F1D5D202A2; Thu, 1 Jul 2010 18:41:55 +0000 (UTC) X-SpamScore: -3 X-BigFish: VPS-3(zz4015Lzz1202hzzz32i2a8h34h62h) X-Spam-TCS-SCL: 1:0 Received: from mail145-va3 (localhost.localdomain [127.0.0.1]) by mail145-va3 (MessageSwitch) id 127800971437847_19203; Thu, 1 Jul 2010 18:41:54 +0000 (UTC) Received: from VA3EHSMHS003.bigfish.com (unknown [10.7.14.245]) by mail145-va3.bigfish.com (Postfix) with ESMTP id EDA4C135804F; Thu, 1 Jul 2010 18:41:53 +0000 (UTC) Received: from ausb3extmailp02.amd.com (163.181.251.22) by VA3EHSMHS003.bigfish.com (10.7.99.13) with Microsoft SMTP Server (TLS) id 14.0.482.44; Thu, 1 Jul 2010 18:41:51 +0000 Received: from ausb3twp02.amd.com ([163.181.250.38]) by ausb3extmailp02.amd.com (Switch-3.2.7/Switch-3.2.7) with SMTP id o61Ijhe1005210; Thu, 1 Jul 2010 13:45:46 -0500 X-M-MSG: Received: from sausexhtp02.amd.com (sausexhtp02.amd.com [163.181.3.152]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Tumbleweed MailGate 3.7.2) with ESMTP id 2831FC85B4; Thu, 1 Jul 2010 13:41:34 -0500 (CDT) Received: from SAUSEXMBP01.amd.com ([163.181.3.198]) by sausexhtp02.amd.com ([163.181.3.152]) with mapi; Thu, 1 Jul 2010 13:41:35 -0500 From: "Fang, Changpeng" To: Richard Guenther , Sebastian Pop CC: Zdenek Dvorak , Christian Borntraeger , "gcc-patches@gcc.gnu.org" , "uweigand@de.ibm.com" Date: Thu, 1 Jul 2010 13:41:34 -0500 Subject: [Patch for suggestions]: How do we know a loop is the peeled version? Message-ID: MIME-Version: 1.0 X-Reverse-DNS: ausb3extmailp02.amd.com Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi, Just found that many optimizations (prefetch, loop unrolling) are performed on the peeled loops. This causes code size and compilation time increase without benefit. MODULE kinds INTEGER, PARAMETER :: RK8 = SELECTED_REAL_KIND(15, 300) END MODULE kinds ! -------------------------------------------------------------------- PROGRAM TEST_FPU ! A number-crunching benchmark using matrix inversion. USE kinds ! Implemented by: David Frank Dave_Frank@hotmail.com IMPLICIT NONE ! Gauss routine by: Tim Prince N8TM@aol.com ! Crout routine by: James Van Buskirk torsop@ix.netcom.com ! Lapack routine by: Jos Bergervoet bergervo@IAEhv.nl REAL(RK8) :: pool(101, 101,1000), a(101, 101) INTEGER :: i DO i = 1,1000 a = pool(:,:,i) ! get next matrix to invert END DO END PROGRAM TEST_FPU For this example (-O3 -fprefetch-loop-arrays -funroll-loops), the vectorizer peels the loop. And the prefetching and loop unrolling are performed on the peeled loops. In the attached patch, the vectorizer marked the loop as peeled, and the prefetching gives up. However, the RTL unroller could not get this information and still unroll the peeled loop. I need suggestion: How the optimizer recognizes that the loop is the peeled version (preloop or postloop)? Thanks, Changpeng From 17fa894c3056bfdf76af19e7ca1d685b9aa4a881 Mon Sep 17 00:00:00 2001 From: Changpeng Fang Date: Thu, 1 Jul 2010 11:27:21 -0700 Subject: [PATCH] Marking peeled loop * cfgloop.h : add peeled filed for loop structure. * tree-vect-loop-manip.c (vect_do_peeling_for_loop_bound): mark new_loop as peeled. * tree-ssa-loop-prefetch.c (loop_prefetch_arrays): Do not do loop prefetch for peeled loop. --- gcc/cfgloop.h | 2 ++ gcc/tree-ssa-loop-prefetch.c | 4 ++++ gcc/tree-vect-loop-manip.c | 1 + 3 files changed, 7 insertions(+), 0 deletions(-) diff --git a/gcc/cfgloop.h b/gcc/cfgloop.h index 3821ee6..f43d6df 100644 --- a/gcc/cfgloop.h +++ b/gcc/cfgloop.h @@ -166,6 +166,8 @@ struct GTY ((chain_next ("%h.next"))) loop { /* Head of the cyclic list of the exits of the loop. */ struct loop_exit *exits; + bool peeled; + /* The single induction variable of the loop when the loop is in normal form. */ tree single_iv; diff --git a/gcc/tree-ssa-loop-prefetch.c b/gcc/tree-ssa-loop-prefetch.c index cde5e18..8a219c3 100644 --- a/gcc/tree-ssa-loop-prefetch.c +++ b/gcc/tree-ssa-loop-prefetch.c @@ -1724,6 +1724,10 @@ loop_prefetch_arrays (struct loop *loop) return false; } + /* Don't do prefetching for peeled loop. */ + if (loop->peeled) + return false; + /* Step 1: gather the memory references. */ refs = gather_memory_references (loop, &no_other_refs, &mem_ref_count); diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c index 8289b36..6bf54f5 100644 --- a/gcc/tree-vect-loop-manip.c +++ b/gcc/tree-vect-loop-manip.c @@ -1905,6 +1905,7 @@ vect_do_peeling_for_loop_bound (loop_vec_info loop_vinfo, tree *ratio, cond_expr, cond_expr_stmt_list); gcc_assert (new_loop); gcc_assert (loop_num == loop->num); + new_loop->peeled = true; #ifdef ENABLE_CHECKING slpeel_verify_cfg_after_peeling (loop, new_loop); #endif -- 1.6.3.3