Re: Mapping of TREE_CODE to tree_node

[Aaron Lorey <lorey.bewerbung@gmail.com>]

Am Mo., 26. Juni 2023 um 20:09 Uhr schrieb David Malcolm <dmalcolm@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.