On Mon, 2013-10-14 at 12:13 +0200, Richard Biener wrote: > On Sat, Oct 12, 2013 at 3:31 AM, David Malcolm <dmalc...@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.
