Re: Continue stmt branch prediction

[Jan Hubicka <hubicka at ucw dot cz>]

> > 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
						    ^^^^ assignments (ie
						    passes tends to look
						    only into RHS of
						    modify statements)
> 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.