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: Andrew Pinski <pinskia at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 29 Jul 2013 11:47:15 -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> <CA+=Sn1=uXBY4AVCEYUAAB8nwRBFK_k+BZBXikGzZb-gqgy1nFg at mail dot gmail dot com> <1374147182 dot 31223 dot 28 dot camel at surprise> <CA+=Sn1kS4PF62ETcEL7KJRcncQy3rhQpYxK7MhyBbVBnaUHtgQ at mail dot gmail dot com>
On Thu, 2013-07-18 at 07:56 -0700, Andrew Pinski wrote:
> On Thu, Jul 18, 2013 at 4:33 AM, David Malcolm <email@example.com> wrote:
> > On Thu, 2013-07-18 at 00:08 -0700, Andrew Pinski wrote:
> >> On Wed, Jul 17, 2013 at 6:18 PM, David Malcolm <firstname.lastname@example.org> 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.
> >> I don't like this patch at all. Mainly because the numbers can get
> >> out of sync very quickly especially when it comes to internal versions
> >> of the compiler where it is normal to reorder passes and add another
> >> pass a few times.
> > How would you feel about a "passes.def.in" and having that be what's in
> > svn, with some kind of preprocessing step that builds a passes.def from
> > it? That way we get the flexibility of before, but gain the ability I'm
> > looking for to make a class holding the passes, and have easy access in
> > gdb to the various instances of the class (rather than just the last
> > instance of each that was created).
> That would work and would be ok with me.
> > If so, what tools are blessed for usage at build time? (I'd prefer
> > Python, but I don't think that's a build-time dep yet).
> So far awk and shell and C programming are the blessed processing
> tools. Awk in this case seems like the best for this though. I don't
> think Python is a good solution only because it does add another build
> dependency that is not there already though I would not complain about
> it if it gets added.
FWIW I implemented this approach, and the result can be seen in:
in the patch series I sent for review on Friday.