Re: Continue stmt branch prediction

[Jan Hubicka <jh@suse.cz>]

> 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