From patchwork Mon May 19 20:37:50 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dehao Chen X-Patchwork-Id: 350393 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 7801E14007B for ; Tue, 20 May 2014 06:38:02 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; q=dns; s=default; b=GUEwxM6Xwgla6OoAMl DdhaMaV54+wMMr2IcWVoPwlLQoTbnV9rvdASVefBCbdJ72icW6g0dJDPKdbnqmhx YXsPazUSb+0IcgtGepHHDMTbyYKF/c7PK9fhoZoZC+sw31a3bxniq9606ht8uLyV P1g8ynjPdDkWdPjxVSRezdRjo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; s=default; bh=xdlST3FTgSRKSjc7umq4zGaS +qM=; b=LFsxZlm9u0SnW99tnclXBZRzpSeFf9u1MEtiKjOr/qOOag9fAqH61BX3 qwdXFlMFI4ydCYVjleaLKu78o1hKS5tLohp53tM/AjTmz5ugtay3IhMDq+UASrmB rlk7pjiuU9c5fIUfvlEBqzK5YoRBnh6PpjD9VLJAbq4YT+ylnZU= Received: (qmail 25361 invoked by alias); 19 May 2014 20:37:54 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 25343 invoked by uid 89); 19 May 2014 20:37:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ie0-f172.google.com Received: from mail-ie0-f172.google.com (HELO mail-ie0-f172.google.com) (209.85.223.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 19 May 2014 20:37:52 +0000 Received: by mail-ie0-f172.google.com with SMTP id tp5so3066390ieb.3 for ; Mon, 19 May 2014 13:37:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3YQ0lFNf44SYfmF2+6QTlQMEGXM1TIfIfadhrgjrLls=; b=GI7TUZoai1Jb3FG111iy58hRyn+uKLKR290rMpUsXwMVLF+PTHYbbb80GNmNBjHI0m Q7NpsoTpwSWQtpjaQnSiyQI49sT4GB5HD+jlp/g4qA5hTHq8Xeae8SXvZ3FKE3noYUlt EF7gA//i2PNUi97eZEdwLPHT6W2GxYjcEJ//aoghTumT5UrvuPINC3ZU8f20QKpcgUp3 IXc8LlMHBePdorUIrOGH3xY0rAhB4wYyKOQggGurFIDOdGrknXKhgmo0YuYf5hiIR5zu EMzk8B9rsAdF6f7DW2KoEJtU0ObZW1zGwrnVo5Bxl59ug9y46w0xXCgshLjbWgqsyZE8 IEuA== X-Gm-Message-State: ALoCoQledT6AtQkE1jbKh+3wSk7WahI5iArqMISm+BV3cqHom425JvzWlCsOzja07WT9ps4gH1nq MIME-Version: 1.0 X-Received: by 10.43.94.9 with SMTP id bw9mr33949292icc.19.1400531870262; Mon, 19 May 2014 13:37:50 -0700 (PDT) Received: by 10.64.18.180 with HTTP; Mon, 19 May 2014 13:37:50 -0700 (PDT) In-Reply-To: <20140517014113.GA10844@kam.mff.cuni.cz> References: <20140516234137.GC28043@kam.mff.cuni.cz> <20140517002207.GD28043@kam.mff.cuni.cz> <20140517014113.GA10844@kam.mff.cuni.cz> Date: Mon, 19 May 2014 13:37:50 -0700 Message-ID: Subject: Re: [PATCH] Ensure count_scale is no larger than REG_BR_PROB_BASE From: Dehao Chen To: Jan Hubicka Cc: GCC Patches , David Li X-IsSubscribed: yes I've updated the patch. Shall I move the check inside cgraph_clone_node? Thanks, Dehao On Fri, May 16, 2014 at 6:41 PM, Jan Hubicka wrote: >> Do you mean adjusting bb->count? Because in >> expand_call_inline(tree-inline.c), it will use bb->count to pass into >> copy_body to calculate count_scale. > > What about taking here callee->count instead? For inline nodes without > any capping hack, bb->count == edge->count = callee->count. > > When profile ends up being obviously inconsistent, I would say that > inliner can cap callee->count during producing the clone... > > Honza >> >> Thanks, >> Dehao >> >> On Fri, May 16, 2014 at 5:22 PM, Jan Hubicka wrote: >> >> In AutoFDO, a basic block's count can be much larger than it's actual >> >> count because debug info might be incorrect. In this case, a call edge >> >> count (calculated from BB count) could be much larger than callee's >> >> header count, making the count_scale incorrectly large. >> > >> > In this case I still think we should handle this when producing the clone: >> > we do not want to have clone's count much larger as well, so i think inliner >> > and ipa-cp needs to deal with capping here instead.... >> > >> > Honza >> >> >> >> Dehao >> >> > >> >> > >> >> > Honza Index: gcc/ipa-inline-transform.c =================================================================== --- gcc/ipa-inline-transform.c (revision 210535) +++ gcc/ipa-inline-transform.c (working copy) @@ -183,8 +183,9 @@ clone_inlined_nodes (struct cgraph_edge *e, bool d if (freq_scale == -1) freq_scale = e->frequency; n = cgraph_clone_node (e->callee, e->callee->decl, - e->count, freq_scale, update_original, - vNULL, true, inlining_into, NULL); + MIN (e->count, e->callee->count), freq_scale, + update_original, vNULL, true, inlining_into, + NULL); cgraph_redirect_edge_callee (e, n); } } Index: gcc/tree-inline.c =================================================================== --- gcc/tree-inline.c (revision 210535) +++ gcc/tree-inline.c (working copy) @@ -4355,7 +4355,7 @@ expand_call_inline (basic_block bb, gimple stmt, c function in any way before this point, as this CALL_EXPR may be a self-referential call; if we're calling ourselves, we need to duplicate our body before altering anything. */ - copy_body (id, bb->count, + copy_body (id, cg_edge->callee->count, GCOV_COMPUTE_SCALE (cg_edge->frequency, CGRAPH_FREQ_BASE), bb, return_block, NULL);