From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57871 invoked by alias); 19 Dec 2018 01:27:06 -0000 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 Received: (qmail 57857 invoked by uid 89); 19 Dec 2018 01:27:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=aklinuxintelcom, ak@linux.intel.com, H*r:ip*209.85.166.194, H*RU:209.85.166.194 X-HELO: mail-it1-f194.google.com Received: from mail-it1-f194.google.com (HELO mail-it1-f194.google.com) (209.85.166.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Dec 2018 01:27:04 +0000 Received: by mail-it1-f194.google.com with SMTP id z7so7266860iti.0 for ; Tue, 18 Dec 2018 17:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k08/2+3YOPogwfLOdYwSvWmB72YTLh8qrYdvndQZZek=; b=aBBsy0aL8wSRVKVdTuFKFO8C74aL7BIes1WgHS69TguwCVHgzfoUKaTopMc4p0Y9AI uG6jxmYqdf9YcvW4nYzcCiBDFcK3rOgXhTUUrYqvPpi6hLnmZHQd7ihzdge7tx1O2QzL iAF168OHbmTkS/E69fTR6muVGkHBUdhhp3m9dE3RipH4WwYMYetBHpkoZD1MIv8s2XqC P4HnljwPWz5Cn8Daj4f540/hQQ0hO0q8JJufADVnIZsA5IaYBwLRc/eIb+Qx2/0+aLKx /4jgqLUIfbqlTt7hdt84/Z4Id+BRMMxOKvFTu+vbVMH5J8f9TMQRduv4UPNLS5DrzP7r J6HA== MIME-Version: 1.0 References: <87wooai8cs.fsf@linux.intel.com> <20181218212736.GH25620@tassilo.jf.intel.com> In-Reply-To: <20181218212736.GH25620@tassilo.jf.intel.com> From: "Bin.Cheng" Date: Wed, 19 Dec 2018 01:27:00 -0000 Message-ID: Subject: Re: [PATCH AutoFDO]Restoring indirect call value profile transformation To: ak@linux.intel.com Cc: bin.cheng@linux.alibaba.com, gcc-patches List Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg01352.txt.bz2 On Wed, Dec 19, 2018 at 5:27 AM Andi Kleen wrote: > > > Yes, take g++.dg/tree-prof/morefunc.C as an example: > > - int i; > > - for (i = 0; i < 1000; i++) > > + int i, j; > > + for (i = 0; i < 1000000; i++) > > + for (j = 0; j < 50; j++) > > g += tc->foo(); > > if (g<100) g++; > > } > > @@ -27,8 +28,9 @@ void test1 (A *tc) > > static __attribute__((always_inline)) > > void test2 (B *tc) > > { > > - int i; > > + int i, j; > > for (i = 0; i < 1000000; i++) > > + for (j = 0; j < 50; j++) > > > > I have to increase loop count like this to get stable pass on my > > machine. The original count (1000) is too small to be sampled. > > IIRC It was originally higher, but people running on slow simulators complained, > so it was reduced. Perhaps we need some way to detect in the test suite > that the test runs on a real CPU. Is there concise way to do this, given gcc may be run on all kinds of virtual scenarios? > > > > > > > FYI, an update about AutoFDO status: > > > > All AutoFDO ICEs in regtest are fixed, while several tests still failing fall in below > > > > three categories: > > > > > > Great! > > > > > > Of course it still ICEs with LTO? > > > > > > Right now there is no test case for this I think. Probably one should be added. > > > Any comments on this? We'd like to further investigate AutoFDO+LTO, may I ask what the status is (or was)? Any background elaboration about this would be appreciated. Thanks, bin > > -Andi