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] Introduce gcc::dump_manager class


On Mon, 2013-10-14 at 12:13 +0200, Richard Biener wrote:
> On Sat, Oct 12, 2013 at 3:31 AM, David Malcolm <dmalcolm@redhat.com> wrote:
> > When repeatedly compiling within one process, the dumpfile numbering
> > doesn't reset, leading to dumpfiles after the initial ones having
> > unpredictable numbers like here (-fdump-tree-all at -O0):
> >
> >       fake.c.000i.cgraph
> >       fake.c.004t.gimple
> >       fake.c.1477t.omplower
> >       fake.c.1478t.lower
> >       (etc)
> >
> > Note the large (and increasing) leap in the numbering from the base
> > dumpfiles which get consistent numbering (000, 004 here) to the
> > autonumbered ones (1477 in this example).  This was due to this implicit
> > state within dump_register:
> >
> >       static int next_dump = FIRST_AUTO_NUMBERED_DUMP;
> >       int num = next_dump++;
> >
> > messing up the numbering on subsequent in-process creation of passes.
> >
> > This patch introduces a new gcc::dump_manager class to hold such state,
> > with a singleton owned by the gcc::context, fixing the inconsistent
> > dumpfile numbering.
> >
> > Specifically, the following variables from dumpfile.c are moved from
> > being statically allocated to being fields of gcc::dump_manager (gaining
> > "m_" prefixes):
> >
> >       * next_dump
> >       * extra_dump_files
> >       * extra_dump_files_in_use
> >       * extra_dump_files_alloced
> >
> > Potentially other aspects of dumping could be moved here, but this
> > seemed like a logically self-contained change.
> >
> > Successfully bootstrapped and regtested on x86_64-unknown-linux.
> >
> > OK for trunk?
> 
> Why can't we have the dump numbering determined at the same time
> we build up the pass pipeline?  That is, why are gcc:dump_manager
> and gcc:pass_manager separate at all?

Not every dumpfile relates to a specific pass: statistics.c registers
and uses a dumpfile in ways that don't look like how the passes do.
Although this is obviously for recording events that happen within
passes, it covers *all* passes, rather than being a per-pass thing.
This is clearly a gray area, but the single responsibility principle
suggests that managing passes vs managing dumpfiles should be separate,
especially since I may want to make future dumpfile-handling cleanups.
(Also, I'm nervous about "blob" classes with too many responsibilities).

> That said, the patch is a trivial re-org and thus ok.

Thanks; committed to trunk as r203569.


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