From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11227 invoked by alias); 5 Mar 2008 22:28:43 -0000 Received: (qmail 11217 invoked by uid 22791); 5 Mar 2008 22:28:42 -0000 X-Spam-Check-By: sourceware.org Received: from atrey.karlin.mff.cuni.cz (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Mar 2008 22:28:24 +0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id 674BAF00F9; Wed, 5 Mar 2008 23:28:22 +0100 (CET) Date: Wed, 05 Mar 2008 22:28:00 -0000 From: Jan Hubicka To: Diego Novillo Cc: Jan Hubicka , Andrew MacLeod , Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: Continue stmt branch prediction Message-ID: <20080305222822.GC14011@atrey.karlin.mff.cuni.cz> References: <20080209194852.GO1026@kam.mff.cuni.cz> <47B0CDB4.3070708@redhat.com> <20080305183319.GH24550@atrey.karlin.mff.cuni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) 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-03/txt/msg00370.txt.bz2 > On Wed, Mar 5, 2008 at 13:33, Jan Hubicka wrote: > > Andrew and Diego, > > can I ask if there was some outcome of the discussion of PREDICT_EXPR > > patch? Looks like the thread just died out without any conclusion about > > the patch itself... > > I'm really hesitant about adding another instruction that does not > seem to have any dataflow nor control flow properties, other than > affecting edges that come out of this block. The semantics of the I will give it one last try. I think the misunderstanding can be here. The prediction hint is not affecting edges *out* of the block it sits in. When lowered, it is affecting all the edges that are going from basic block not postdominated by the block to basic block postdominated by the block (here the course of execution is crossing the point that it inavoidably leads to the place PREDICT_EXPR is). Think of abort call: it is affecting all conditionals that are guarding it in the program. PREDICT_EXPR is sort of marker in the program saying that this place is unlikely for reasons that are no longer obvious from lowered IL. It is not part of other control flow construct and it is not part of other instruction in a sense that the high level construct it originated from migh've expended to nothing (as continue statement does, it is translated to GOTO_EXPR that is very soon removed by CFG construction and translated to edge that is usually very soon removed by CFG cleanup). It is just sort of no-op instruction. Making the marker part of some other instruction (GOTO_EXPR) would introduce need to forcingly keep that GOTO around until the lowering happends (and it can't happen at CFG construction, since it works better after some early cleanups and inlining). Not undoable but it seems less clean than PREDICT_EXPR to me. In fact it seems to me as bad as adding any other side effect to GOTO_EXPR via flag. Na > instruction are very vague to me and I can't shake the idea that the > FE could put these attributes in the jumps or conditionals or switches > that it generates which we then convert into edge attributes. > > I feel I'm being dense here and I'm totally missing your point. Sorry. > > > Diego.