On Thu, May 18, 2017 at 11:08:51AM -0400, Nathan Sidwell wrote:
> On 05/16/2017 11:26 AM, Nathan Sidwell wrote:
> > This patch breaks apart the creation of the pass manager from
> > gcc::context's ctor. This will allow us to register additional dumps
> ... https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01295.html
>
> This patch builds upon the context creation patch (this diff includes it),
> to implement a new LANG_HOOK_REGISTER_DUMPS language hook. I call it
> between creating the dump manager and instantiating the optimization passes.
>
> The patch then uses the hook to move the current -fdump-class-hierarchy
> option into the C++ FE entirely, removing TDI_class and associated handling
> from dumpfile and c-family/c-opts.c. The option gets renamed to
> -fdump-lang-class in the process.
>
> Obviously -fdump-translation-unit is the next candidate, and possibly
> -fdump-tree-original.
This breaks the dump numbering.
On some simple source file with some OpenMP pragmas in it, with C
and -fopenmp -fdump-tree-all I'm getting (so unless one knows the order
of passes, the indexes and file order no longer reveal the actual pass
sequence):
1.c.003t.omplower
1.c.003t.original
1.c.004t.gimple
1.c.004t.lower
1.c.007t.eh
1.c.008t.cfg
1.c.009t.ompexp
...
The right order is .original, .gimple, then (not included) .nested,
then .omplower, .lower, etc.
With C++ -fopenmp -fdump-tree-all I'm getting:
1.c.003t.original
1.c.004t.gimple
1.c.005t.omplower
1.c.006t.lower
1.c.008t.ehopt
1.c.009t.eh
...
which is slightly better, but there is no space for e.g. the .nested
dump. With -fopenmp -fdump-tree-all -fdump-lang-all and C++ I'm getting
1.c.003t.original
1.c.004l.raw
1.c.004t.gimple
1.c.005t.omplower
1.c.006t.lower
1.c.008t.ehopt
1.c.009t.eh
...
so there is a number clash in between the raw and gimple dumps in addition
to the nested vs. omplower.
So, first question, where should we order the -fdump-lang-* dumps, shall
they go before .original/.gimple/.nested, or in between .original and
.gimple/.nested, or after those 3 (the last option looks just wrong to me)?
Shall the 3 standard dumps be registered like any others?
Shall the number of lang dumps affect the numbering, i.e. is it desirable
that with C and C++ you get different numbers for *t.cfg dump, or *t.gimple?
In many cases it would be better if the numbering was consistent between C
and C++.
Jakub
