This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 3/4] Introduce NEXT_PASS_NUM macro


On Thu, 2013-07-18 at 07:56 -0700, Andrew Pinski wrote:
> 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.

FWIW I implemented this approach, and the result can be seen in:
  http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01263.html
in the patch series I sent for review on Friday.

Thanks
Dave


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]