Re: Continue stmt branch prediction

[Jan Hubicka <hubicka at ucw dot cz>]

> On Wed, Mar 5, 2008 at 13:33, Jan Hubicka <hubicka@ucw.cz> 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.