[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    My additional mechanism for dumping intermediate tree representations.
From:       "Simon Hill" <yacwroy () gmail ! com>
Date:       2008-11-29 7:30:40
Message-ID: fc3094d10811282330v52871c38sb3ecad5cb73eb62c () mail ! gmail ! com
[Download RAW message or body]

It took me quite some time to figure out how to browse the different
types of trees that I am interested in.
There are still many types and components that I will need later to
finish my restrictive exception specification warning mechanic.

I've tried dumping trees but the format of the dumps isn't too useful
for learning the underlying format.
The standard dump just reformats it as something looking somewhat
similar to a C function.
The raw dump isn't structured so you have to search for node numbers
in order to parse the tree, which makes it very cumbersome.

I have just put together some quick generic nested-tree output code
and I'm using it to dump some parts of a tree.
It is very far from finished as I have to add the different tree-types.
I'm working from tree-dump.c:deque_and_dump().
So far it looks like:
=====================================================================
func(0x7fffa8e60d00): decl:tree(function_decl). at test/throw.cpp:10.
  >-DECL_NAME(0x7fffa8e6a1e0): id:tree(identifier_node).
  |   >-IDENTIFIER_POINTER(0x11695b6): foo.
  |   \-IDENTIFIER_LENGTH(0x7fffa8e6a208): 3.
  |
  >-DECL_ASSEMBLER_NAME(0x7fffa8e6a960): id:tree(identifier_node).
  |   >-IDENTIFIER_POINTER(0x116960b): _Z3foov.
  |   \-IDENTIFIER_LENGTH(0x7fffa8e6a988): 7.
  |
  >-TREE_TYPE(0x7fffa8e6d240): type:tree(function_type).
  |   >-TYPE_MAIN_VARIANT(0x7fffa97d3e40): type:tree(function_type).
  |   |   \-TYPE_SIZE(0x7fffa97a87b0): unk:tree(integer_cst).
const:tree(integer_cst). const.
  |   |       >-int_cst.int_cst.low(0x7fffb1921184): 8.
  |   |       >-int_cst.int_cst.high(0x7fffb1921180): 0.
  |   |       \-TREE_TYPE(0x7fffa97bb0c0): type:tree(integer_type).
  |   |           >-TYPE_NAME(0x7fffa97ca240): id:tree(identifier_node).
  |   |           |   >-IDENTIFIER_POINTER(0x112e769): bit_size_type.
  |   |           |   \-IDENTIFIER_LENGTH(0x7fffa97ca268): 13.
  |   |           |
  |   |           \-TYPE_SIZE(0x7fffa97a8b40): unk:tree(integer_cst).
expr:tree(integer_cst). const.
  |   |               >-int_cst.int_cst.low(0x7fffb1920e44): 64.
  |   |               \-int_cst.int_cst.high(0x7fffb1920e40): 0.
  |   |
  |   \-TYPE_SIZE(0x7fffa97a87b0): unk:tree(integer_cst).
const:tree(integer_cst). const.
  |       >-int_cst.int_cst.low(0x7fffb19212b4): 8.
  |       >-int_cst.int_cst.high(0x7fffb19212b0): 0.
  |       \-TREE_TYPE(0x7fffa97bb0c0): type:tree(integer_type).
  |           >-TYPE_NAME(0x7fffa97ca240): id:tree(identifier_node).
  |           |   >-IDENTIFIER_POINTER(0x112e769): bit_size_type.
  |           |   \-IDENTIFIER_LENGTH(0x7fffa97ca268): 13.
  |           |
  |           \-TYPE_SIZE(0x7fffa97a8b40): unk:tree(integer_cst).
const:tree(integer_cst). const.
  |               >-int_cst.int_cst.low(0x7fffb1920f74): 64.
  |               \-int_cst.int_cst.high(0x7fffb1920f70): 0.
  |
  \-TREE_CHAIN(0x7fffa8e60c30):
=====================================================================
At present it's picking up many things it shouldn't (eg type of a
TYPE_SIZE) and discarding many that it should care about (eg func
params & statement list), but that's the general format of the dump.
I'm guessing it'll average out around 30 dumped lines per code line.

I'm currently getting it to dump inside -fdump-tree-original to that
dump's target file (which dumps once per function), but it can be
called anywhere on any tree.
Do you think this would be useful to people (especially beginners)? It
would certainly have been useful to me, and the tree structure
documentation is unfinished.
It would probably be useful as it's own dump entry, say
-fdump-tree-original-nodetree or something.
[prev in list] [next in list] [prev in thread] [next in thread]