Continue stmt branch prediction

[Jan Hubicka]

> On 3/5/08 2:28 PM, Jan Hubicka wrote:
> 
> >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.
> 
> Ah, I see now.  Yes, I think I finally got your point.  Adding 
> PREDICT_EXPR is fine with me.

Great :)
Thanks for time needed to get through this!
> 
> Instead of having to special-case it in places like DCE, how about we 
> make it produce a value which is assigned to an artificial volatile 
> global temporary?  This way, we don't need to touch the optimizers, they 
> will all naturally back away from moving and/or removing it.

This decision is definitly up to you.  I can definitly make PREDICT_EXPR
an expression tree instead of GIMPLE statement and put it into
MODIFY_EXPR destinating some dummy volatile.  This seems bit hackish way
to me to save one case label in DCE: DCE is a bit special among the
early passes in a way that it does worry about more side effects of
statements beside the usual operands+semantics of statements all the
other propagation passes are about.  DCE has to know all GIMPLE
statement types (and it just aborts on any new). I would tend to argue
that with exception of DCE we can hardly come with early scalar cleanup
pass that really do care here and will need to special case MODIFY_EXPR
statement.

Honza
> 
> 
> Diego.