From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10311 invoked by alias); 1 Feb 2019 04:12:24 -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 10264 invoked by uid 89); 1 Feb 2019 04:12:19 -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=sampling X-HELO: mail-io1-f42.google.com Received: from mail-io1-f42.google.com (HELO mail-io1-f42.google.com) (209.85.166.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Feb 2019 04:12:17 +0000 Received: by mail-io1-f42.google.com with SMTP id s22so4639611ioc.8 for ; Thu, 31 Jan 2019 20:12:17 -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=P7KlBCLktF0JG18yGYR1QkCLfjn7MAsOKWnLyWeF1ok=; b=BBZK9R2T2tYdkaIXaJEbpExCYvjOcugy8GW/ZbsJyewWS/4atbs3TnVEEltelUHqwE EaRUlffyJkQo/YXocNtOlSVkrEwFAJiyeacVifVRAOOulOHxBFJnylFJKYVgKenElKIn Mu7aRAADzBDIWY5JSbXuN+tJCUXuUPJysbie7epfa+Tfvx0WBM8pFsp3CWW5LCYlfXAd 4g1eStDBUViRv00Uvyn1daoNlCicNwDQeG33UPOPnqNb8W1tOjdcMDNfOLz0fHro3TQu SOAGcOgxuXLav/ARblvpFMq1hJV8eZCr2bxljGZRlbhFMLJ25mHvjppbWX0n3Jy+1kC8 u2vg== MIME-Version: 1.0 References: <87wooai8cs.fsf@linux.intel.com> <20190114080726.GD6118@tassilo.jf.intel.com> <20190114171055.GE6118@tassilo.jf.intel.com> In-Reply-To: <20190114171055.GE6118@tassilo.jf.intel.com> From: "Bin.Cheng" Date: Fri, 01 Feb 2019 04:12:00 -0000 Message-ID: Subject: Re: [PATCH AutoFDO]Restoring indirect call value profile transformation To: Andi Kleen Cc: bin.cheng@linux.alibaba.com, gcc-patches List Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00005.txt.bz2 On Tue, Jan 15, 2019 at 1:10 AM Andi Kleen wrote: > > On Mon, Jan 14, 2019 at 04:15:20PM +0800, Bin.Cheng wrote: > > On Mon, Jan 14, 2019 at 4:07 PM Andi Kleen wrote: > > > > > > Bin Cheng, > > > > > > I did some testing on this now. The attached patch automatically increases the iterations > > > for autofdo profiles. > > Hi Andi, thanks very much for tuning these. > > > > > > But even with even more iterations I still have stable failures in > > > > > > FAIL: gcc.dg/tree-prof/cold_partition_label.c scan-assembler foo[._]+cold > > > FAIL: gcc.dg/tree-prof/cold_partition_label.c scan-assembler size[ \ta-zA-Z0-0]+foo[._]+cold > > I think these two are supposed to fail with current code base. > > Sorry for being late. > We should mark it as XFAIL then I guess. Yeah > > Is it understood why it doesn't work? I didn't dig into it, but I think the reason is autofdo::zero count is not considered as cold as profile count. It's kind of reasonable, otherwise too much code would be categorized as cold. > > > > FAIL: gcc.dg/tree-prof/indir-call-prof.c scan-ipa-dump afdo "Indirect call -> direct call.* a1 transformation on insn" > > I also got unstable pass/fail for indirect call optimization when > > tuning iterations, and haven't got an iteration number which passes > > all the time. I guess we need to combine decreasing of sampling count > > here. > > Okay I will look into that. > > Could also try if prime sample after values help, this sometimes fixes > problems with systematically missing some code in sampling. > > > > FAIL: gcc.dg/tree-prof/peel-1.c scan-tree-dump cunroll "Peeled loop ., 1 times" > > This one should fail too. > > Same. Maybe I shouldn't use words "should fail", but the reason is we don't consider autofdo profile count as reliable in niters analysis. Maybe this can be improved somehow. Thanks, bin > > -Andi