This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 29 Jul 2013 15:32:20 -0400
- Subject: Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro
- References: <1374110303-9758-1-git-send-email-dmalcolm at redhat dot com> <1374110303-9758-4-git-send-email-dmalcolm at redhat dot com> <51E816EE dot 6050504 at redhat dot com>
On Thu, 2013-07-18 at 10:25 -0600, Jeff Law wrote:
> On 07/17/2013 07:18 PM, David Malcolm wrote:
> > gcc/
> > Explicitly number the instances of passes within passes.def.
> > This is needed by a subsequent patch so that we can create
> > fields within the pipeline class for each pass instance (to help
> > locate pass instances when debugging).
> > * passes.c (NEXT_PASS_NUM): Define.
> > * passes.def (NEXT_PASS, NEXT_PASS_NUM): Replace uses of
> > NEXT_PASS on passes that have multiple instances with uses of
> > NEXT_PASS_NUM.
> So this means we have to track down the instance number if we add a
> duplicate pass in the pipeline. I can see positives and negatives of
> doing that. I'll go along as I'm a proponent of the goal of having the
> passes be a first class object.
> Ok for the trunk.
Thanks. Out of interest, what do you see as the positives and
Given Andrew's objections to managing pass instance numbers by hand, I
went with an alternate approach, and wrote an awk script to generate a
pass-instances.def from passes.def at build time:
in the patch series I sent for review on Friday.
This approach would give us the uniqueness I was looking for (so that
the pass_manager class can have fields tracking all the pass instances),
avoids having to maintain the numbers by hand, and also gives us an easy
way of e.g. seeing how many pass_copy_prop instances we have, and what
their instance numbers are (see the example of the result at: