This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Introduce gcc::dump_manager class
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 14 Oct 2013 13:58:27 -0400
- Subject: Re: [PATCH] Introduce gcc::dump_manager class
- Authentication-results: sourceware.org; auth=none
- References: <1381541486 dot 1809 dot 14 dot camel at surprise> <CAFiYyc0no3QrxAXw3sABYeJYO_MxB1_BAHTHKWVxyPNj3mbSVA at mail dot gmail dot com>
On Mon, 2013-10-14 at 12:13 +0200, Richard Biener wrote:
> On Sat, Oct 12, 2013 at 3:31 AM, David Malcolm <firstname.lastname@example.org> 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.