This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro
- From: Jeff Law <law at redhat dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 29 Jul 2013 13:59:52 -0600
- 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> <1375126340 dot 23374 dot 92 dot camel at surprise>
On 07/29/2013 01:32 PM, David Malcolm wrote:
Positives being the uniqueness (which you need). Negatives are
maintenance as we add passes, in particular if a pass is run more than once.
On Thu, 2013-07-18 at 10:25 -0600, Jeff Law wrote:
On 07/17/2013 07:18 PM, David Malcolm wrote:
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
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.
Which is even better.