From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73857 invoked by alias); 3 Feb 2020 16:23:43 -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 73792 invoked by uid 89); 3 Feb 2020 16:23:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=invent, H*MI:sk:f89f0a4, H*f:sk:f89f0a4, H*i:sk:f89f0a4 X-HELO: nikam.ms.mff.cuni.cz Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Feb 2020 16:23:40 +0000 Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202) id 10D22280401; Mon, 3 Feb 2020 17:23:38 +0100 (CET) Date: Mon, 03 Feb 2020 16:23:00 -0000 From: Jan Hubicka To: Jeff Law Cc: Pat Haugen , Jiufu Guo , gcc-patches@gcc.gnu.org, wschmidt@linux.ibm.com, segher@kernel.crashing.org, pthaugen@us.ibm.com Subject: Re: [PATCH] correct COUNT and PROB for unrolled loop Message-ID: <20200203162337.GK22868@kam.mff.cuni.cz> References: <1580717822-6073-1-git-send-email-guojiufu@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-SW-Source: 2020-02/txt/msg00084.txt.bz2 > On Mon, 2020-02-03 at 10:04 -0600, Pat Haugen wrote: > > On 2/3/20 2:17 AM, Jiufu Guo wrote: > > > +/* { dg-final { scan-rtl-dump-times "REG_BR_PROB 937042044" 1 "loop2_unroll"} } */ > > > > Sorry I didn't catch this addition to the original testcase earlier, but I wonder how stable this test is going to be. If there are future changes to default count/probability, or changes in their representation, this may fail and need to be updated. The fact that the loop is still getting aligned is the main concern. > Unless you're really interested in those probabilities, I'd suggest not > testing for them. If you really need to test for them, then I'd > suggest testing for them being "close" rather than a specific value for > REG_BR_PROB. Note that REG_BR_PROB now encodes the actual probability as well as the profile quality (i.e. it is m_val * 8 + m_quality). We may want to invent better way to dump them, but it is better to match for CFG edge probability rather than the REG_BR_PROB_NOTE. honza > > jeff >