This is the mail archive of the
mailing list for the GCC project.
Re: Thoughts about semantics of BB_VISITED
> 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
> 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.