Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro

[Andrew Pinski <pinskia at gmail dot com>]

On Thu, Jul 18, 2013 at 4:33 AM, David Malcolm <dmalcolm@redhat.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 <dmalcolm@redhat.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.

Thanks,
Andrew Pinski