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


> 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.


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