This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: Allow passes to return TODO flags
On Thu, 2006-03-02 at 12:29 -0500, Diego Novillo wrote:
> On 03/02/06 12:20, Daniel Jacobowitz wrote:
>
> > would let us add e.g. a new dump related flag to every pass fairly
> > simply.
> >
> Right. That's the tradeoff I want to analyze.
>
> I'm not completely convinced that option 1 (remove todo_flags_finish) is
> the best path. It's true that some passes will want to *add* stuff to
> it. The question I have is "will passes need to *remove* items from the
> TODO set?". I'm leaning towards "no".
>
> And, now that I think more about it, if a pass were to need removing
> items from its TODO list, we could simply just not put that item as a
> default and allow the pass to add it in those cases.
>
> So, I think I've now changed my mind. Let the field stay and have the
> passes return a bitmask of *additional* items they want the pass manager
> to do.
Ponder this case that has been in the back of my mind for years...
In a pipeline of optimization passes, some later passes may
only be useful if an earlier pass actually performed some
transformations.
The classic example would be the large Plum Hall expression tests;
we have no need for the later CSE passes because the loop optimizers
do nothing for those tests. Avoiding the later CSE pass would speed
up compilation of those tests by 20-30% back in the day.... (probably
less now since the relative percentage of time spend in CSE is smaller).
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.
In that kind of world we'd have a set of toplevel optimizers
and a set of optimizers which are conditionally run based on
the todo status set by the toplevel optimizers.
Jeff