From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19591 invoked by alias); 14 Feb 2008 18:27:44 -0000 Received: (qmail 19578 invoked by uid 22791); 14 Feb 2008 18:27:43 -0000 X-Spam-Check-By: sourceware.org Received: from nikam-dmz.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 14 Feb 2008 18:27:23 +0000 Received: from localhost (occam.ms.mff.cuni.cz [195.113.18.121]) by nikam.ms.mff.cuni.cz (Postfix) with ESMTP id 30C905B82F; Thu, 14 Feb 2008 19:27:21 +0100 (CET) Received: by localhost (Postfix, from userid 16202) id 2791F93743; Thu, 14 Feb 2008 19:27:21 +0100 (CET) Date: Thu, 14 Feb 2008 19:12:00 -0000 From: Jan Hubicka To: Andrew MacLeod Cc: Jan Hubicka , Richard Guenther , Jan Hubicka , gcc-patches@gcc.gnu.org, dnovillo@google.com Subject: Re: Continue stmt branch prediction Message-ID: <20080214182721.GC8931@kam.mff.cuni.cz> References: <20080209194852.GO1026@kam.mff.cuni.cz> <47B0CDB4.3070708@redhat.com> <20080214151154.GA8931@kam.mff.cuni.cz> <84fc9c000802140730n52133795yee4a7a341808da59@mail.gmail.com> <20080214174122.GA32085@atrey.karlin.mff.cuni.cz> <47B4844D.2010007@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47B4844D.2010007@redhat.com> User-Agent: Mutt/1.5.9i 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/msg00512.txt.bz2 > Jan Hubicka wrote: > >>Wouldn't it be easier to add a unlikely_goto stmt for all these and > >>translate > >>that to edge probabilities once we build the cfg? That is, stick the > >>unlikely > >>bit onto the goto stmt instead of having an extra predict_expr floating > >>around. > >> > > > >We've disucussed this few mails back. The problem is that if you have > >something like > > > >if (something) > > something2 > > goto somewhere else > > > >somewhere else: > > something_else > > > >then after gimplifing we get > > > > > >if (something) goto around > >something2 > >somewehre_else > >around: > > > >and goto is gone. It is really more a property of the some specific > > > This example doesn't seem right. You've just changed the meaning of the > 'if' in your example... At least the way I read it. you are no longer > executing 'something2' if 'something' is true, nor executing 'something > else' on both paths as in the original case. There are too many Hehe, I really messed up gimplification. I meant to do block merging of something2 and somethign_else blocks to show that the goto stateemnts are often easilly eliminated early in compilation and that the source level control flow is not that directly related to what we want to have in CFG. > different things you could have meant for me to guess exactly what you > did mean :-) > > I'll try tho :-) > > Did you perhaps mean to reverse the condition to if (!something) in the > latter case? If so, then you seem to be arguing that since the original Yes. > 'if''s code segment contained an explicit GOTO, that the end result is > we should predict that it is unlikely to be taken, and therefore we > should predict that the 'if (!something) goto around' branch *will* be > taken after gimplifying, and that we lose that info. > > Is that correct or were you trying to say something else? Yes, it is correct. Sorry for the confussion. Honza > > Andrew