Re: Thoughts about semantics of BB_VISITED

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> Zdenek Dvorak wrote:
> 
> >it does not change them -- they must be clear on the entry, and they are
> >clear on the exit.  Aand this is by far the simplest way.  On contrary,
> >I believe that the optimization passes should not use these flags.
> >While inside the shared utility there is at least some justification for
> >it (it saves you passing bitmap to it and other trouble), I see no
> >justification why for example PRE cannot use sbitmap instead of touching
> >BB_VISITED.
> >
> Absolutely not.  With this approach you are merely muddling the 
> interface to helper functions.  A helper function should not rely on 
> implicit initialization of global data.  The BB_VISITED bit is a 
> globally shared attribute, assuming anything about it inside a helper 
> function is a recipe for confusion and hard-to-track bugs.
> 
> This is akin to helper functions assuming that TREE_VISITED is clear on 
> entry.  Passes use TREE_VISITED in a variety of ways.  Helpers and, 
> particularly, read-only helpers should not be modifying shared data.

When I introduced this flag, my intention for it was that it should be
used only inside utility functions for marking the part of cfg they work
with; i.e. I never expected it to be used by any optimization pass
directly.  I obviously should have written it to comments; sorry for
that.  Perhaps I should create a new bb flag for this original purpose,
document it clearly, and leave BB_VISITED for whatever purposes the
optimizations use it.

Zdenek