This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Continue stmt branch prediction

On Thu, Mar 13, 2008 at 2:37 AM, Jan Hubicka <> wrote:
> > 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.

I also think this is a hack and adjusting DCE sounds more natural.  A
volatile global will also affect optimization because of the needed


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]