From patchwork Tue Oct 15 14:56:29 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dehao Chen X-Patchwork-Id: 283659 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 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 1609D2C00C7 for ; Wed, 16 Oct 2013 01:56:46 +1100 (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=OVhDk3a6mtr7QV6bKa gmPQUeKFONDwtUYnr+roRGHNZUDP2TnUNvG3tHVSLdjeXL6RmSGoP/Nlbu3x8Iy0 Gd2tih4rxSkp0Rd83ZDY9fHUpGsKs/Xaj9kn6enX1Iwla1Cyyur/b8Gy1qS8gs6r P8+zx59KdfUrJXBJxKseAqL5Y= 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=zS42aRozBfTw3+slT0VXKBju cx8=; b=Ow4RVJWysQoNDm6fOhlaOqO0K9Q/siwzvZAuXF9E9rntA4oDOYEProY3 8Oz/EHrzvEBzN84dj2WNEkAe0Ow3/ZT4xlfq6VPtgSQpVITCHFjWl5fQ4MpoAtpy OZ+BhdLYjby6e481sMZpEQBZRxIWqzO0kAyZrxOwMoSXABC2okA= Received: (qmail 23796 invoked by alias); 15 Oct 2013 14:56:34 -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 23747 invoked by uid 89); 15 Oct 2013 14:56:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.5 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-f175.google.com Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 15 Oct 2013 14:56:32 +0000 Received: by mail-ie0-f175.google.com with SMTP id aq17so12831121iec.6 for ; Tue, 15 Oct 2013 07:56:29 -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=i8BI6ysxtjVhg/6xxQ5KDwNTHN6GSLFjIuNPjhAKd9U=; b=mfi/83JZLQ60Bn9X8/mduiyymJRq5Im/mSQstF0GMhBI20Xdv1YZj52Oxoq9E2vOaf WYzm3lvcbDGF9cSXunzPwlbFWuf0jTPpCjQ3oG+ZczWnvHjC412BNG9c/7s/ym+szG19 9UTCl90vmGJf8nPFUsMaYqCc3a8LZw+0ohrz6L2M7oOsMcjP4GUNGC0YSZjpbVslYElp sC3avP9azw1rWnxJVP6P2wEIdHdCedv0QDlvDnMJL6Th0VQiWkYMJH6mLh3Kihmn0fnA nJR4bamxeEGhNTLdGADiuuoliBSdMnwtwaXUPBbWFHQ+1eEEaHonXhdRzqVwegBLdaW6 dYyQ== X-Gm-Message-State: ALoCoQng29mkZ071HY2JHrhSQUcq8R3uS1F9XzsXBBON1Mm6iLSLFXT4GAVybgcY4aI/2quZCHAHjz7XFq2t23BSMEzYUBtiYmk4yMkXjwiwb44HsnsKwJCU18Ts/kXZ/KEKwEFuJoQvFwEZTXPjJvUzfr5Ox5JyL1244XcIzKjk6OqzqhPQaLhScKpAhfSB1jleXp+rNA9f518kegDguMsufhoX6z6Zsw== MIME-Version: 1.0 X-Received: by 10.50.85.114 with SMTP id g18mr17375514igz.15.1381848989694; Tue, 15 Oct 2013 07:56:29 -0700 (PDT) Received: by 10.64.9.133 with HTTP; Tue, 15 Oct 2013 07:56:29 -0700 (PDT) In-Reply-To: References: <20131014194908.GA16717@kam.mff.cuni.cz> <20131014215027.GD17422@kam.mff.cuni.cz> Date: Tue, 15 Oct 2013 07:56:29 -0700 Message-ID: Subject: Re: [PATCH] decide edge's hotness when there is profile info From: Dehao Chen To: Jan Hubicka Cc: Xinliang David Li , GCC Patches X-IsSubscribed: yes The patch updated: Thanks, Dehao On Mon, Oct 14, 2013 at 3:26 PM, Dehao Chen wrote: > On Mon, Oct 14, 2013 at 2:50 PM, Jan Hubicka wrote: >>> For my test case, the entire inline instance is optimized away, so >>> there is no info about it in the profile. I can do some fixup in the >>> rebuild_cgraph_edge though. >> >> Yep, I understand that. In this case we should turn PROFILE_READ to PROFILE_GUESSED >> and guess the profile when we detect this (i.e. we have edges with non-0 counts into >> functions with 0 profile). That should prvent these from getting UNLIKELY_EXECUTED >> and they will be inlined normal way. > > Oh, actually in AutoFDO, only functions with samples will be marked as > PROFILE_READ. Others will all be marked as PROFILE_GUESSED. > > Dehao > >> >> Honza >>> >>> Dehao >>> >>> On Mon, Oct 14, 2013 at 2:27 PM, Xinliang David Li wrote: >>> > Is it possible to update the callee node summary after profile >>> > annotate (using information from inline instances which are not >>> > inlined in early inline)? >>> > >>> > David >>> > >>> > On Mon, Oct 14, 2013 at 2:18 PM, Dehao Chen wrote: >>> >> On Mon, Oct 14, 2013 at 12:49 PM, Jan Hubicka wrote: >>> >>>> Not for instrumented FDO (not as I know of). But for AutoFDO, this >>> >>>> could be a potential risk because some callee is marked unlikely >>> >>>> executed simply because they are inlined and eliminated in the O2 >>> >>>> binary. But in ipa-inline it will not get inlined because the edge is >>> >>>> not hot from cgraph_maybe_hot_edge_p (because callee is >>> >>>> UNLIKELY_EXECUTED), while the edge->count is actually hot. >>> >>> >>> >>> Can't you prevent setting calle to UNLIKELY_EXECUTED in these cases instead? >>> >>> It seems that having profile set incorrectly will lead to other problems later, too. >>> >>> We discussed similar problem with Teresa about the missing profiles for comdat, >>> >>> basically one should detect these cases as profile being lost and go with guessed >>> >>> profile. (I believe patch for that was posted, too, and so far it seems best approach >>> >>> to this issue) >>> >> >>> >> The current AutoFDO implementation will take all functions that do not >>> >> have have profile as normally executed, thus use guessed profile for >>> >> it. This is like using profile for truly hot functions, and using O2 >>> >> for other functions. This works fine. However, it leads to larger code >>> >> size (approximately 10%~20% larger than FDO). >>> >> >>> >> I'd like to introduce another mode for users who care about both >>> >> performance and code size, and can be sure that profile is >>> >> representative. In this mode, we will mark all functions without >>> >> sample as "unlikely executed". However, because AutoFDO use debug info >>> >> (of optimized code) to represent profile, it's possible that some hot >>> >> functions (say foo) are inlined and fully eliminated into another hot >>> >> function (say bar). So in the profile, bar is cold, and because the >>> >> profile for foo::bar is eliminated, bar will not be inlined into foo >>> >> before the profile annotation. However, after profile annotate, we can >>> >> infer from the bb count that foo->bar is hot, thus it should be >>> >> inlined in ipa-inline phase. However, because bar itself is marked >>> >> UNLIKELY_EXECUTED, it will not be inlined. >>> >> >>> >> One possible workaround would be that during rebuild_cgraph_edges, if >>> >> we find an edge's callee is unlikely executed, add the edge count to >>> >> the callee's count and recalculate callee's frequency. >>> >> >>> >> Dehao >>> >> >>> >>> >>> >>> Honza Index: gcc/cgraph.c =================================================================== --- gcc/cgraph.c (revision 203609) +++ gcc/cgraph.c (working copy) @@ -877,6 +877,10 @@ cgraph_create_edge_1 (struct cgraph_node *caller, if (call_stmt && caller->call_site_hash) cgraph_add_edge_to_call_site_hash (edge); + if (count > 0 && edge->callee + && edge->callee->frequency == NODE_FREQUENCY_UNLIKELY_EXECUTED) + edge->callee->frequency = NODE_FREQUENCY_NORMAL; + return edge; }