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: Thoughts about semantics of BB_VISITED


> >Currently, individual passes are free to assume that the BB_VISITED flag 
> >will always be clear on every basic block before they start.
> >
> >I find these semantics rather error prone, as they assume that previous 
> >passes will have been good citizens and cleared flags on their way out.  
> >It's pretty easy to forget and it makes for potentially difficult to track 
> >bugs.
> >
> >What's worse is that we may end up doing double work (like in PRE), where 
> >we first traverse all the blocks asserting that the bit is cleared and at 
> >the end do another loop clearing the flag.
> >
> >We don't seem to have that semantics on TREE_VISITED, why do it on blocks 
> >then?
> I didn't quite understand why either, but Zdenek told me that this is the 
> way it was (he's the one that added that code in PRE).
> Maybe he can tell us the reason we do this?

as far as I remember, the reason is that the flag is used on some places
that work only with a part of cfg (something like doing dfs over only
body of a single loop).  So you can use the fact that BB_VISITED is 0,
mark just the loop and clear the marks afterwards.

If the state of the mark would be undefined, you would need either to
clean them up first (over whole cfg), or use bitmaps for the marks.
Both of these approaches bring a risk of quadratic behavior.

If you find the semantics error-prone, why not to add a check to
verify_cfg that would ensure it is always satisfied?


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