From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20612 invoked by alias); 16 Dec 2010 17:24:06 -0000 Received: (qmail 20565 invoked by uid 22791); 16 Dec 2010 17:24:05 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from db3ehsobe001.messaging.microsoft.com (HELO DB3EHSOBE001.bigfish.com) (213.199.154.139) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Dec 2010 17:23:59 +0000 Received: from mail84-db3-R.bigfish.com (10.3.81.250) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.8; Thu, 16 Dec 2010 17:23:56 +0000 Received: from mail84-db3 (localhost.localdomain [127.0.0.1]) by mail84-db3-R.bigfish.com (Postfix) with ESMTP id DF5696806E; Thu, 16 Dec 2010 17:23:55 +0000 (UTC) X-SpamScore: -12 X-BigFish: VPS-12(zz4015L9371P10d1Izz1202hzz8275dhz32i668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null);UIP:(null);IPVD:NLI;H:ausb3twp02.amd.com;RD:none;EFVD:NLI Received: from mail84-db3 (localhost.localdomain [127.0.0.1]) by mail84-db3 (MessageSwitch) id 129252022574709_18254; Thu, 16 Dec 2010 17:23:45 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.250]) by mail84-db3.bigfish.com (Postfix) with ESMTP id BCCEEA30061; Thu, 16 Dec 2010 17:23:03 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server id 14.1.225.8; Thu, 16 Dec 2010 17:22:51 +0000 X-M-MSG: Received: from sausexedgep01.amd.com (sausexedgep01-ext.amd.com [163.181.249.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ausb3twp02.amd.com (Tumbleweed MailGate 3.7.2) with ESMTP id 2C847C872E; Thu, 16 Dec 2010 11:22:44 -0600 (CST) Received: from sausexhtp01.amd.com (163.181.3.165) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 16 Dec 2010 11:24:51 -0600 Received: from SAUSEXMBP01.amd.com ([163.181.3.198]) by sausexhtp01.amd.com ([163.181.3.165]) with mapi; Thu, 16 Dec 2010 11:22:48 -0600 From: "Fang, Changpeng" To: Zdenek Dvorak , Richard Guenther CC: Xinliang David Li , "gcc-patches@gcc.gnu.org" Date: Thu, 16 Dec 2010 18:26:00 -0000 Subject: RE: [PATCH, Loop optimizer]: Add logic to disable certain loop optimizations on pre-/post-loops Message-ID: References: <20101214075629.GA10020@kam.mff.cuni.cz> <20101214210552.GA19633@kam.mff.cuni.cz> <20101215092220.GA9872@kam.mff.cuni.cz> ,<20101216120914.GA15902@kam.mff.cuni.cz> In-Reply-To: <20101216120914.GA15902@kam.mff.cuni.cz> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: amd.com 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: 2010-12/txt/msg01318.txt.bz2 My initial intention is Not to unroll prologue and epilogue loops. An estim= ated trip count may not be that useful for the unrolling decision. To me, unrolling a loop = that has at most=20 3 (or 7) iterations does not make sense. RTL unrolling does not use the est= imated trip=20 count to determine the unroll factor, and thus it may still unroll the loop= 4 or 8 times if the loop is small ( #insns). To make things simple, we just don't unroll su= ch loops. However, a prologue or epilogue loop may still be a hot loop, depending on = the outer=20 loops. It may still be beneficial to perform other optimizations on such lo= ops, if the code size is not expanded multiple times. For prefetching of prologue or epilogue loops, we have two choices (1) pref= etching not=20 not unrolling, (2) not prefetching. Which one do you prefer? Thanks, Changpeng ________________________________________ From: Zdenek Dvorak [rakdver@kam.mff.cuni.cz] Sent: Thursday, December 16, 2010 6:09 AM To: Richard Guenther Cc: Xinliang David Li; Fang, Changpeng; gcc-patches@gcc.gnu.org Subject: Re: [PATCH, Loop optimizer]: Add logic to disable certain loop opt= imizations on pre-/post-loops Hi, > Btw, any reason why we do not use static profiles for number of iteration > estimates? We after all _do_ use the static profile to guide the > maybe_hot/cold_bb tests. for loops for that we cannot determine the # of iterations statically, basically the only important predictors are PRED_LOOP_BRANCH and PRED_LOOP_EXIT, which predict that the loop will iterate about 10 times. S= o, by using static profile, we would just learn that every such loop is expect= ed to iterate 10 times, which is kind of useless, Zdenek