From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64442 invoked by alias); 25 Sep 2015 16:56:17 -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 64428 invoked by uid 89); 25 Sep 2015 16:56:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 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-ig0-f171.google.com Received: from mail-ig0-f171.google.com (HELO mail-ig0-f171.google.com) (209.85.213.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 25 Sep 2015 16:56:14 +0000 Received: by igbkq10 with SMTP id kq10so15999866igb.0 for ; Fri, 25 Sep 2015 09:56:12 -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=3yPHq08ByN0XsDHnHUxnicRp7CGeOzRtzsLnjQWhiJc=; b=I4VbJAtoO8sw1O5C5m9ig9MZIRqORKd8lGSsk9uqcZHrfl1+/lzSdLHbCsqtj99HFn pjFScnyo+rG6OqEcDRMMzpXitHmGLJOk+1+9C3oR6EEeQF3sW1WOCQDlu021wiXcPT33 UJuuZbxvTMKLFddjSUw8VsibmSELxEvf/iYGmjCMMo+IuQuSA+5pPlZXsGlE5M5eMYZA Y8tMNfP/5h5Qx16D0Hs3C4yVJUqQqIxtfTYEXEz5NMi38UydCzvXbmFnKeJTRTMd/3FO /J6O5j3OFWHk9Wj5DaRKnZFbD6M3OseoshWBKEtQIk7qdrX6Alpd1ge83IKjCmfX8f/3 +SmQ== X-Gm-Message-State: ALoCoQl5dhkCkx+DD5RoXT11HD4B57aJzZ0UQfTqAieknGfot1azw8Dnk1uDZRXjLKbm6G0DIPqN MIME-Version: 1.0 X-Received: by 10.50.3.104 with SMTP id b8mr4004518igb.15.1443200171860; Fri, 25 Sep 2015 09:56:11 -0700 (PDT) Received: by 10.107.34.203 with HTTP; Fri, 25 Sep 2015 09:56:11 -0700 (PDT) In-Reply-To: <20150925143447.GI59241@kam.mff.cuni.cz> References: <56055316.6080901@redhat.com> <20150925143447.GI59241@kam.mff.cuni.cz> Date: Fri, 25 Sep 2015 16:58:00 -0000 Message-ID: Subject: Re: [PATCH] Disable -fno-reorder-blocks-and-partition if no -fprofile-use to avoid unnecessary overhead From: Teresa Johnson To: Jan Hubicka Cc: Bernd Schmidt , "gcc-patches@gcc.gnu.org" , Xinliang David Li Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg01999.txt.bz2 On Fri, Sep 25, 2015 at 7:34 AM, Jan Hubicka wrote: >> > What has changed between then and now? Also, do we not use >> > estimates/heuristics when not using a profile? >> >> Nothing has changed - splitting effectively never kicked in without a >> profile. Honza and I had discussed the idea that static profile >> heuristics could eventually be used to distinguish hot vs cold bbs, > > Yep, the basic idea was to move EH clenaups to the cold section for start. The > cleanup code can get surprisingly large for some C++ apps. > >> but that hasn't happened. What I didn't notice until recently was the >> size increase in the .o files from varasm adding in unnecessary >> sections and labels when this option was on. Unless and until static > > Perhaps we also may just teach varasm to not output those when function is not > split. I am happy with the patch as it is because it is pointless to run the > code when no splitting happens. Right, that will need to happen if splitting is tuned for static frequencies. For now I committed this patch. I also fixed the old change log entry that Bernd pointed out. Thanks, Teresa > > Honza >> heuristics are used to distinguish cold bbs in >> probably_never_executed_bb_p, I don't think it makes sense to do >> anything finer grained that just disabling the option. >> >> Teresa >> >> > >> > >> > Bernd >> >> >> >> -- >> Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413 -- Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413