On Wed, May 24, 2017 at 07:44:49AM -0400, Nathan Sidwell wrote:
> On 05/24/2017 06:57 AM, Jakub Jelinek wrote:
> 
> > 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)?
> 
> I think the lang dumps should come first.
> 
> > Shall the 3 standard dumps be registered like any others?
> 
> I think they should move to the new dynamic registration.
> Should 'original' become a lang dump?

It would be great if the original dumping was able to use some FE specific
printing, right now the *.original dump is often full of
<<cleanup_point <<< Unknown tree: expr_stmt
and similar stuff.  It is desirable that it is provided by every FE though
if it is a lang dump.
On the other side there are 370+ tests that use -fdump-tree-original.

> > 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++.
> 
> I'm ambivalent on this.  I can see why consistency might be desirable
> though.  I'd be fine with making the lang dumps unnumbered to achieve that
> -- I don't see an obvious need for a language to have two dumps of the same
> name.

The numbering is not to differentiate between dumps of the same name, that
is done through numbered suffixes of the dump names, but to make the order
of passes visible to the user and for sorted file listing to be provided in
that order.  So, rather than having lang files unnumbered, I think it is
better to number them and just have a maximum of lang dumps and if some FE
registers fewers, bump m_next_dump accordingly (create a hole).
That is pretty much the standard behavior, if some dump is registered, but
for whatever reason not dumped, you also get a hole.

        Jakub

Reply via email to