From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1141 invoked by alias); 14 Dec 2010 19:13:52 -0000 Received: (qmail 1122 invoked by uid 22791); 14 Dec 2010 19:13:50 -0000 X-SWARE-Spam-Status: No, hits=-2.0 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; Tue, 14 Dec 2010 19:13:43 +0000 Received: from mail25-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.8; Tue, 14 Dec 2010 19:13:40 +0000 Received: from mail25-va3 (localhost.localdomain [127.0.0.1]) by mail25-va3-R.bigfish.com (Postfix) with ESMTP id 4F30211F0267; Tue, 14 Dec 2010 19:13:40 +0000 (UTC) X-SpamScore: -8 X-BigFish: VPS-8(zz1453M4015Lzz1202hzzz32i668h61h) 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 mail25-va3 (localhost.localdomain [127.0.0.1]) by mail25-va3 (MessageSwitch) id 1292354020216989_30387; Tue, 14 Dec 2010 19:13:40 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.252]) by mail25-va3.bigfish.com (Postfix) with ESMTP id 3248BEC8052; Tue, 14 Dec 2010 19:13:40 +0000 (UTC) Received: from ausb3twp02.amd.com (163.181.249.109) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server id 14.1.225.8; Tue, 14 Dec 2010 19:13:39 +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 26674C86F0; Tue, 14 Dec 2010 13:13:31 -0600 (CST) Received: from sausexhtp02.amd.com (163.181.3.152) by sausexedgep01.amd.com (163.181.36.54) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 14 Dec 2010 13:15:33 -0600 Received: from SAUSEXMBP01.amd.com ([163.181.3.198]) by sausexhtp02.amd.com ([163.181.3.152]) with mapi; Tue, 14 Dec 2010 13:13:37 -0600 From: "Fang, Changpeng" To: Zdenek Dvorak CC: "gcc-patches@gcc.gnu.org" Date: Tue, 14 Dec 2010 20:02: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> In-Reply-To: <20101214075629.GA10020@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/msg01122.txt.bz2 >why not simply change the profile updating to correctly indicate that the= se loops do not roll? >That way, all the optimizations would profit, not just those aware of the = new bb flag, Maybe my understanding is not correct. But I feel not comfortable using pro= file of trip count to guard loop optimizations. For a given program, different data sizes will= result in quite different loop trip counts. By the way, what optimizations else do you think will benefit from disablin= g for small trip count loops, significantly?=20 Thanks, Changpeng=20=20