[PATCH]: Allow passes to return TODO flags

Daniel Berlin dberlin@dberlin.org
Thu Mar 2 17:27:00 GMT 2006


On Thu, 2006-03-02 at 12:20 -0500, Daniel Jacobowitz wrote:
> On Thu, Mar 02, 2006 at 12:19:40PM -0500, Daniel Berlin wrote:
> > On Thu, 2006-03-02 at 11:19 -0500, Diego Novillo wrote:
> > > On 03/02/06 11:06, Daniel Berlin wrote:
> > > 
> > > > I kept todo_flags_finish, otherwise almost every pass is going to return
> > > > TODO_dump_func | TODO_ggc_collect, TODO_dump_func | TODO_verify_ssa |
> > > > TODO_verify_stmt, or some variant thereof.
> > > > 
> > > I think I would rather remove the todo_flags_finish field and make each
> > > pass return *exactly* the bitmask with TODO items.  This gives much
> > > finer control over what the passes need doing afterwards (and a much
> > > longer rope to hang itself with, but I think I prefer it this way).
> 
> Won't this be a real pain if we need to make mechanical changes in the
> future?  Whereas this:
> 
> > > The other alternative is to keep todo_flags_finish and have the pass
> > > return the *additional* set of TODO items for the pass manager.  That,
> > > however, gives the passes less control.
> > 
> > Which is what the patch does now :)
> 
> would let us add e.g. a new dump related flag to every pass fairly
> simply.

Yes.

Personally, i prefer keeping todo_flags_finish because

1. It seems silly to have a todo_flags_start without a todo_flags_finish
2. Having to remember to add return TODO_dump_func | TODO_ggc_collect |
TODO_blah_blah at every exit point from the execute function seems a bit
silly.

If the pass wants to control exactly the flags it returns, it can always
make todo_flags_finish 0.
:)

> 



More information about the Gcc-patches mailing list