This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Thoughts about semantics of BB_VISITED
Hello,
> >>>because get_loop_body is often used on places where (lots of) new blocks
> >>>get created (like unroller). Resizing the sbitmap would be quite
> >>>annoying.
> >>
> >>Also, it's quite annoying to have to keep resetting these flags. I don't
> >>think a simple read-only helper should be altering the basic block flags.
> >>All i did was ask for the loop body.
> >
> >it does not change them -- they must be clear on the entry, and they are
> >clear on the exit.
>
> It will clear them if they aren't cleared, at least on some blocks. This
> is obvious from the definition of dfs_enumerate_from.
no, it is obvious that dfs_enumerate_from does not work unless the marks
are clear.
> Also, t requires you to change them before calling the routine, or the
> routine
> breaks.
No, it just requires them to be kept clear (and preferably not used
anywhere else). I am sorry I did not put comment at BB_VISITED when
I created the flag; given the level of missuse of it inside various
optimizations, it is too late :-(
> This is the same as if the routine changed them itself, which it does (it
> clears them).
>
> I'll note that other get_loop_* routines, like get_loop_body_in_dom_order,
> don't touch any visited flags.
At the cost of being more expensive.
> Also, if you > 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.
>
> This just makes no sense to me, because you are saying we should do the
> same thing you don't want get_loop_body to have to do.
Because it is simple thing to do in optimization, but quite cumbersome
for this utility function.
Zdenek