From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20990 invoked by alias); 14 Feb 2008 15:38:14 -0000 Received: (qmail 20972 invoked by uid 22791); 14 Feb 2008 15:38:11 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 14 Feb 2008 15:37:46 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m1EFbi6P002198; Thu, 14 Feb 2008 10:37:44 -0500 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m1EFbhb6028476; Thu, 14 Feb 2008 10:37:43 -0500 Received: from [10.13.248.51] (vpn-248-51.boston.redhat.com [10.13.248.51]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m1EFbfxh021191; Thu, 14 Feb 2008 10:37:41 -0500 Message-ID: <47B46044.2050006@redhat.com> Date: Thu, 14 Feb 2008 15:45:00 -0000 From: Andrew MacLeod User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Jan Hubicka CC: gcc-patches@gcc.gnu.org, dnovillo@google.com Subject: Re: Continue stmt branch prediction References: <20080209194852.GO1026@kam.mff.cuni.cz> <47B0CDB4.3070708@redhat.com> <20080214151154.GA8931@kam.mff.cuni.cz> In-Reply-To: <20080214151154.GA8931@kam.mff.cuni.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2008-02/txt/msg00502.txt.bz2 >> What are the other predictors? It might help to understand it better if >> we had a better overview of everything PREDICT_EXPR was going to do. >> > > I was mostly looking into following stuff: > 1) the continue bit > 2) explicit goto statements are usually not executed > 3) default path of C switch statement on emum with all named fields > explicit is unlikely > 4) expanded bounds checks (ie arrays tends to be in bounds. We used to > have PRED_MUDLFAP here but it was dropped and Java has similar logic) > 5) expanded openMP constructs > 6) higher level constructs from non-C frontends we have. There are > cases where we produce control flow expanding stuff like fortran > vectors where we have unlikely paths through. Though I didn't look > into great detail into this yet. > > We already handle same way the calls to noreturn functions and functions > marked via cold attribute, but those are easilly recognized on gimple > and don't need extra marker. > > So if I get the idea: When these higher level constructs are being lowered, their usual behaviour is used to place PREDICT_EXPR into the insn stream to indicate whether this path code is likely to be executed or not. And these PREDICT_EXPR's just bob along in the code stream as its moved around so that later on, we can reconstruct the likely paths by scanning the IL. Their primary function is to modify branch probabilities from what would otherwise be the default? Whether they are created or not affects nothing but branch probabilities (and of course generated code performance, but never correctness). And if they somehow ended up in the wrong place, again, it only affects probabilities? So there is therefore no flow or other side effects from these expressions. These thing primarily exist before we get around to being able to annotate branches and such with probabilities of being taken, and once that happens, we chuck them never to be seen again? And they also indicate nothing but TRUE if this is an expected code path, or FALSE if its not expected. Is that more or less correct? Andrew