Am Mo., 26. Juni 2023 um 20:09 Uhr schrieb David Malcolm <dmalc...@redhat.com>: > > On Mon, 2023-06-26 at 18:59 +0200, Aaron Lorey via Gcc wrote: > > Hello, > > > > this is the first time I am writing to a mailing list. I've tried > > researching the normal procedure but nothing special seems to be > > required. > > > > I'm currently trying to do a complete graph-discovery of GCC's symtab > > / > > tree_nodes to dump the full internal representation of the > > compilation > > unit. Gitlab: https://gitlab.com/graph-prog/code-database > > > > It is not exceptionally heavy but also not very easy to serialize the > > internal state to disk. I think this task was simply not considered > > in the > > design. > > > > Reason for writing to the mailing list are the troubles in connecting > > the > > TREE_CODE enumeration to the appropriate struct tree_node memory > > layout > > without guessing. > > > > Can you provide a mapping of TREE_CODE to tree_node memory layout? > > I don't know that such a mapping exists directly, but have a look at > the functions "tree_code_size" and "tree_size" defined in gcc/tree.cc. > > You might also find the LTO streaming code of interest; see gcc/lto- > streamer-{in,out}.cc > > Hope this is helpful > Dave > >
Thank you for your reply. The tree_size() and tree_code_size() functions are useful, although incomplete. If I understand correctly, the link time optimization works on the GIMPLE representation. The original syntax tree and symbol table would be preferable. Andrew's suggestion might be more what I'm looking for.
