This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH]: Allow passes to return TODO flags


> A more modern example, after VRP or DOM, we really don't need to
> do any const/copy propagation cleanups if no jumps were threaded.
> 
> The point is I'd like whatever scheme we're moving towards to be
> able to be able to handle those kind of cases.  In a lot of ways
> it means that we'd have todo properties for things like 
> const/copy propagation, redundancy elimination, etc.

This is something i've thought a bit about.

Currently we try to use global state to control this in some places,
which is very ugly.

I believe the todo flag returning is a step in the right direction.

However, for passes which are very far away, the only way to get this
kind of behavior is somewhat ugly, because it requires maintaining some
type of state to know what the set of things you want done eventually
is.

You'd basically stop guaranteeing that the TODO_flags that control
optimizations (or probably, a separate but similar mechanism to say what
opts to run, i'm just calling it "todo" for simplicity) will be run
immediately, and pass the todo set to the gate functions.
they'd then decide whether to run their opt based on whether the todo
flag still was about.

If you hit a pass with the todo flag in the todo_start flags, you have
to execute the thing you've been delaying.

Of course, before any of this makes sense, you'll have to solve pass
ordering problems all the rtl opts seem to have that most of the tree
cleanup passes (fre, ccp, dom) really don't.

--Dan


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