This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro
- From: Andrew Pinski <pinskia at gmail dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 18 Jul 2013 07:56:08 -0700
- 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>
On Thu, Jul 18, 2013 at 4:33 AM, David Malcolm <firstname.lastname@example.org> wrote:
> On Thu, 2013-07-18 at 00:08 -0700, Andrew Pinski wrote:
>> On Wed, Jul 17, 2013 at 6:18 PM, David Malcolm <email@example.com> 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.