Thoughts about semantics of BB_VISITED

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Zdenek Dvorak
> Sent: 07 January 2005 19:55

> > >>>>>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.
> > >>>>>
> > >>>>
> > >>>>Quadratic behaviour?  How?
> > >>>
> > >>>
> > >>>because the places where it is used now (most notably, 
> get_loop_body)
> > >>>do not look at whole cfg, but just at the loop body.
> > >>>
> > >>Oh, I see.  So, this is inside a helper, not a pass.  How 
> unfortunate.
> > >>Perhaps get_loop_body should not use BB_VISITED.  What if the pass
> > >>calling get_loop_body is using BB_VISITED for its own processing?
> > >
> > >then it is doomed :-(.  Quite often there is no real 
> reason why a pass
> > >should use BB_VISITED -- it can simply use sbitmap of 
> basic blocks instead.
> > 
> > Why can't one just pass an sbitmap to get_loop_body, instead of it 
> > destroying visited flags without telling you?
> 
> 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.
> 
> Zdenek


  Well then, size it big enough to deal with a best-guess-approximation to a
likely figure for the number of blocks it might end up needing to represent, and
only if it grows beyond that resize it, again leaving plenty of room for
expansion to cut down on repeated calls to the resize code.  Or would that have
too great a knock-on effect on memory usage?


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....