This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Yet another tree dumper

On Oct 14, 2003, at 11:51 AM, Jason Merrill wrote:

In the past, people expressed interest to see debug_tree()
alternative. Here it is. Try it in your local source tree and
see if it is good enough. If it has problems, let me know.

I'm not going to accept a whole new dumper that serves the same purpose as
debug_tree; that's way too much code duplication. If you don't like how
debug_tree works currently, change it so that it works the way you want.

We looked at debut_tree implementation earlier. And it seemed easier and cleaner to write dmp_tree.

Or argue that your new dumper is strictly better than debug_tree and should
replace it.

I can try that!

There are many advantages of dmp_tree().
- It produced condensed display with appropriate indentation.
- It makes easier to map tree internals to actual source.
- It annotates various tree operands appropriately.
  For example:
    ARRAY_REF operands are annotated as "(base)" and "(index)".
    COND_EXPR operands are annotated as "(cond)", "(?), ":"
    CALL_EXPR operands are annotated as "(func)", "(args)" etc...
- It is more human readable. For example, it knows how to display
  parm_decls appropriately form compound stat for given function decl.
  (It adds empty line to separate them out.)

(from my previous example ...)

 parm_decl:0x40e294fc t=0x40ce9488 {int} line=7 ...  i
 parm_decl:0x40e29570 t=0x40ce932c {char} line=7  ... j
 parm_decl:0x40e295e4 t=0x40cf1ae0 {float} line=7  ... k
 expr_stmt:0x40e19730 (dummy, to be deleted) 0x40e054c0

compound_stmt:0x40e19744 line=8 0x0

It is very difficult to find i,j and k parameter info in debug_tree
output. dmp_tree() uses one line for each parameter and all of
them are indented at the same level. neat and clean.

- It does not print useless information. For example dmp_tree() for
  function decl does not print details of function type. It just
  puts  "  t=0x40ce9488 {function_type}" on the first line. Where as
  debug_tree() emits function_type details and this makes difficult
  collect info about function decl itself.
- It prints "(dummy, to be deleted)" at appropriate place :-)

and so on..

Either way, there can be only one.

Yes, I'd like to replace debug_tree() with dmp_tree().

I am sure dmp_tree() will improve GCC developer's productivity.
But suddenly removing debug_tree() may negatively affect
developers if their eyes are used to debug, debug_tree()
output on the fly. It may take some time to understand all
advantages of dmp_tree (and fix any hidden bugs :-)).

So we can have transition strategy, where both dumper lives
together for some time and then debug_tree() is eventually
replaced by dmp_tree(). OR couple of debug_tree() users
try my patch for few days in their local tree and tell us
their opinion.

What do you think?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]