Re: [PATCH] Kill -fdump-translation-unit

[Rainer Orth]

Hi Nathan,

> On 05/11/2017 01:33 PM, Rainer Orth wrote:
>
>> unfortunately, this part
>>
>>  * graphite-poly.c: Don't include tree-dump.h.
>>
>> broke bootstrap with graphite:
>
> oh, that has to be configured enabled?  I've committed this that I think is

right: it requires an appropriate version of libisl at configure time.

> obvious.  looks to be another case of using tree-dumph to get at
> dumpfile.h.

Fine, thanks.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Kill -fdump-translation-unit

[Nathan Sidwell]

On 05/11/2017 01:33 PM, Rainer Orth wrote:


unfortunately, this part

* graphite-poly.c: Don't include tree-dump.h.

broke bootstrap with graphite:


oh, that has to be configured enabled?  I've committed this that I think 
is obvious.  looks to be another case of using tree-dumph to get at 
dumpfile.h.


nathan

--
Nathan Sidwell
2017-05-11  Nathan Sidwell  

	* graphite-poly.c: Include dumpfile.h.

Index: graphite-poly.c
===
--- graphite-poly.c	(revision 247916)
+++ graphite-poly.c	(working copy)
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3.
 #include "pretty-print.h"
 #include "gimple-pretty-print.h"
 #include "graphite.h"
+#include "dumpfile.h"
 
 /* Print to STDERR the GMP value VAL.  */
 

Re: [PATCH] Kill -fdump-translation-unit

[Rainer Orth]

Hi Nathan,

> On 05/10/2017 04:49 AM, Richard Biener wrote:
>> On Tue, May 9, 2017 at 5:41 PM, Nathan Sidwell  wrote:
>>> -fdump-translation-unit is an inscrutably opaque dump.  It turned out that
>>> most of the uses of the tree-dump header file was to indirectly get at
>>> dumpfile.h, and the dump_function entry point it had forwarded to a dumper
>>> in tree-cfg.c.  The gimple dumper would use its node dumper when asked for a
>>> raw dump, but that was about it.
>>>
>>> We have prettier printers now.  This patch nukes the tu dumper.  ok?
>>
>> Ok if nobody objects within 24 hours.
>
> sigh, apparently not.  I committed this to at least clean up the header
> file twistiness.

unfortunately, this part

* graphite-poly.c: Don't include tree-dump.h.

broke bootstrap with graphite:

/vol/gcc/src/hg/trunk/local/gcc/graphite-poly.c: In function "void 
new_poly_dr(poly_bb_p, gimple*, poly_dr_type, isl_map*, isl_set*)":
/vol/gcc/src/hg/trunk/local/gcc/graphite-poly.c:108:7: error: "dump_file" was 
not declared in this scope
   if (dump_file)
   ^

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH] Kill -fdump-translation-unit

[Nathan Sidwell]

On 05/10/2017 04:49 AM, Richard Biener wrote:

On Tue, May 9, 2017 at 5:41 PM, Nathan Sidwell  wrote:

-fdump-translation-unit is an inscrutably opaque dump.  It turned out that
most of the uses of the tree-dump header file was to indirectly get at
dumpfile.h, and the dump_function entry point it had forwarded to a dumper
in tree-cfg.c.  The gimple dumper would use its node dumper when asked for a
raw dump, but that was about it.

We have prettier printers now.  This patch nukes the tu dumper.  ok?


Ok if nobody objects within 24 hours.


sigh, apparently not.  I committed this to at least clean up the header 
file twistiness.


nathan

--
Nathan Sidwell
2017-05-11  Nathan Sidwell  

	* dumpfle.h (dump_function): Declare here ...
	* tree-dump.h (dump_function): ... not here.
	* dumpfile.c: #include tree-cfg.h.
	(dump_function): Move here from ...
	* tree-dump.c (dump_function): ... here.
	* gimplify.c: #include splay-tree.h, not tree-dump.h.
	* graphite-poly.c: Don't include tree-dump.h.
	* cgraphclones.c: Include dumpfile.h not tree-dump.h.
	* print-tree.c: Likewise.
	* stor-layout.c: Likewise.
	* tree-nested.c: Likewise.

	c/
	* gimple-parser.c: Don't #include tree-dump.h.

	fortran/
	* trans-decl.c: Include dumpfile.h not tree-dump.h,
	
Index: c/gimple-parser.c
===
--- c/gimple-parser.c	(revision 247909)
+++ c/gimple-parser.c	(working copy)
@@ -53,7 +53,6 @@ along with GCC; see the file COPYING3.
 #include "tree-ssanames.h"
 #include "gimple-ssa.h"
 #include "tree-dfa.h"
-#include "tree-dump.h"
 
 
 /* Gimple parsing functions.  */
Index: cgraphclones.c
===
--- cgraphclones.c	(revision 247909)
+++ cgraphclones.c	(working copy)
@@ -78,7 +78,7 @@ along with GCC; see the file COPYING3.
 #include "tree-eh.h"
 #include "tree-cfg.h"
 #include "tree-inline.h"
-#include "tree-dump.h"
+#include "dumpfile.h"
 #include "gimple-pretty-print.h"
 
 /* Create clone of edge in the node N represented by CALL_EXPR
Index: dumpfile.c
===
--- dumpfile.c	(revision 247909)
+++ dumpfile.c	(working copy)
@@ -26,6 +26,7 @@ along with GCC; see the file COPYING3.
 #include "diagnostic-core.h"
 #include "dumpfile.h"
 #include "context.h"
+#include "tree-cfg.h"
 
 /* If non-NULL, return one past-the-end of the matching SUBPART of
the WHOLE string.  */
@@ -980,6 +981,22 @@ dump_basic_block (int dump_kind, basic_b
 dump_bb (alt_dump_file, bb, indent, TDF_DETAILS);
 }
 
+/* Dump FUNCTION_DECL FN as tree dump PHASE.  */
+
+void
+dump_function (int phase, tree fn)
+{
+  FILE *stream;
+  int flags;
+
+  stream = dump_begin (phase, );
+  if (stream)
+{
+  dump_function_to_file (fn, stream, flags);
+  dump_end (phase, stream);
+}
+}
+
 /* Print information from the combine pass on dump_file.  */
 
 void
Index: dumpfile.h
===
--- dumpfile.h	(revision 247909)
+++ dumpfile.h	(working copy)
@@ -147,6 +147,7 @@ extern const char *dump_flag_name (int);
 extern void dump_printf (int, const char *, ...) ATTRIBUTE_PRINTF_2;
 extern void dump_printf_loc (int, source_location,
 			 const char *, ...) ATTRIBUTE_PRINTF_3;
+extern void dump_function (int phase, tree fn);
 extern void dump_basic_block (int, basic_block, int);
 extern void dump_generic_expr_loc (int, source_location, int, tree);
 extern void dump_generic_expr (int, int, tree);
Index: fortran/trans-decl.c
===
--- fortran/trans-decl.c	(revision 247909)
+++ fortran/trans-decl.c	(working copy)
@@ -35,7 +35,7 @@ along with GCC; see the file COPYING3.
 #include "stor-layout.h"
 #include "varasm.h"
 #include "attribs.h"
-#include "tree-dump.h"
+#include "dumpfile.h"
 #include "toplev.h"	/* For announce_function.  */
 #include "debug.h"
 #include "constructor.h"
Index: gimplify.c
===
--- gimplify.c	(revision 247909)
+++ gimplify.c	(working copy)
@@ -56,7 +56,7 @@ along with GCC; see the file COPYING3.
 #include "gimple-low.h"
 #include "cilk.h"
 #include "gomp-constants.h"
-#include "tree-dump.h"
+#include "splay-tree.h"
 #include "gimple-walk.h"
 #include "langhooks-def.h"	/* FIXME: for lhd_set_decl_assembler_name */
 #include "builtins.h"
Index: graphite-poly.c
===
--- graphite-poly.c	(revision 247909)
+++ graphite-poly.c	(working copy)
@@ -39,7 +39,6 @@ along with GCC; see the file COPYING3.
 #include "tree-data-ref.h"
 #include "pretty-print.h"
 #include "gimple-pretty-print.h"
-#include "tree-dump.h"
 #include "graphite.h"
 
 /* Print to STDERR the GMP value VAL.  */
Index: print-tree.c
===
--- print-tree.c	(revision 247909)
+++ 

Re: [PATCH] Kill -fdump-translation-unit

[Nathan Sidwell]

On 05/10/2017 01:58 PM, Jakub Jelinek wrote:


A quick search indicates that people have published .tu parsers in Perl, JS
(producing json), the person objecting on IRC apparently used Python, and I'm
aware of another Python-based parser by Bruce Merry.


Prior to Alex mentioning it, I was unaware of such parsers -- I'm 
surprised.  This is not a data interchange format, it's a debugging dump.


The fellow on IRC failed to mention that, and made the claim that the TU 
dump was the simplest way of determining sizeof (time_t) when one has a 
cross compiler.


nathan

--
Nathan Sidwell

Re: [PATCH] Kill -fdump-translation-unit

[Alexander Monakov]

On Wed, 10 May 2017, Jakub Jelinek wrote:
> Can it at least be taken out of -fdump-tree-all?  It is huge, often larger
> than the sum of all the other dump files, and don't remember ever using it
> for anything.

Yes, apart from advertising the capability I don't imagine it's useful to
produce that dump without a special flag.


> Instead of trying to write a parser for it and reconstructing
> something you can then later analyze, isn't it better to just write a plugin
> that can analyze it directly?

I think I can understand people writing a parser when it's sufficient; it won't
need to be recompiled for a specific compiler version (with headers from that
compiler), won't crash the compiler if you did something wrong.  For people more
familiar with a dynamic language like Python than C/C++ it may be just more
comfortable to do it that way.

Alexander

Re: [PATCH] Kill -fdump-translation-unit

[Jakub Jelinek]

On Wed, May 10, 2017 at 08:51:22PM +0300, Alexander Monakov wrote:
> On Wed, 10 May 2017, Richard Biener wrote:
> 
> > On Tue, May 9, 2017 at 5:41 PM, Nathan Sidwell  wrote:
> > > -fdump-translation-unit is an inscrutably opaque dump.  It turned out that
> > > most of the uses of the tree-dump header file was to indirectly get at
> > > dumpfile.h, and the dump_function entry point it had forwarded to a dumper
> > > in tree-cfg.c.  The gimple dumper would use its node dumper when asked 
> > > for a
> > > raw dump, but that was about it.
> > >
> > > We have prettier printers now.  This patch nukes the tu dumper.  ok?
> > 
> > Ok if nobody objects within 24 hours.
> 
> There was a reasonable IMO objection on the IRC (sadly, I can't say the same
> about the responses that person received from Nathan).
> 
> A quick search indicates that people have published .tu parsers in Perl, JS
> (producing json), the person objecting on IRC apparently used Python, and I'm
> aware of another Python-based parser by Bruce Merry.
> 
> My takeaway from this is that people cared enough about this to build and
> publish parsers in their language of choice, and that apparently it is or was
> feature-rich enough for them to use.  Despite the format being undocumented 
> and
> formally not supported.
> 
> The motivation put forward in the opening mail ("is an inscutably opaque 
> dump")
> seems like a weak reason for removal.

Can it at least be taken out of -fdump-tree-all?  It is huge, often larger
than the sum of all the other dump files, and don't remember ever using it
for anything.  Instead of trying to write a parser for it and reconstructing
something you can then later analyze, isn't it better to just write a plugin
that can analyze it directly?

Jakub

Re: [PATCH] Kill -fdump-translation-unit

[Alexander Monakov]

On Wed, 10 May 2017, Richard Biener wrote:

> On Tue, May 9, 2017 at 5:41 PM, Nathan Sidwell  wrote:
> > -fdump-translation-unit is an inscrutably opaque dump.  It turned out that
> > most of the uses of the tree-dump header file was to indirectly get at
> > dumpfile.h, and the dump_function entry point it had forwarded to a dumper
> > in tree-cfg.c.  The gimple dumper would use its node dumper when asked for a
> > raw dump, but that was about it.
> >
> > We have prettier printers now.  This patch nukes the tu dumper.  ok?
> 
> Ok if nobody objects within 24 hours.

There was a reasonable IMO objection on the IRC (sadly, I can't say the same
about the responses that person received from Nathan).

A quick search indicates that people have published .tu parsers in Perl, JS
(producing json), the person objecting on IRC apparently used Python, and I'm
aware of another Python-based parser by Bruce Merry.

My takeaway from this is that people cared enough about this to build and
publish parsers in their language of choice, and that apparently it is or was
feature-rich enough for them to use.  Despite the format being undocumented and
formally not supported.

The motivation put forward in the opening mail ("is an inscutably opaque dump")
seems like a weak reason for removal.

Alexander

Re: [PATCH] Kill -fdump-translation-unit

[Richard Biener]

On Tue, May 9, 2017 at 5:41 PM, Nathan Sidwell  wrote:
> -fdump-translation-unit is an inscrutably opaque dump.  It turned out that
> most of the uses of the tree-dump header file was to indirectly get at
> dumpfile.h, and the dump_function entry point it had forwarded to a dumper
> in tree-cfg.c.  The gimple dumper would use its node dumper when asked for a
> raw dump, but that was about it.
>
> We have prettier printers now.  This patch nukes the tu dumper.  ok?

Ok if nobody objects within 24 hours.

Thanks,
Richard.

> nathan
>
> --
> Nathan Sidwell