On Wed, Feb 28, 2024 at 08:58:08AM +0100, Richard Biener wrote:
> Incidentially this looks like something fit for a google summer of code
> project.
> Ideally it would hook into print-tree.cc providing an alternate
> structured output.
> It currently prints in the style
>
> <function_decl 0x7ffff71bc600 bswap16
> type <function_type 0x7ffff71ba5e8
> type <integer_type 0x7ffff702b540 short unsigned int public unsigned
> HI
> size <integer_cst 0x7ffff702d108 constant 16>
> unit-size <integer_cst 0x7ffff702d120 constant 2>
> align:16 warn_if_not_align:0 symtab:0 alias-set -1
> canonical-type 0x7ffff702b540 precision:16 min <integer_cst
> 0x7ffff702d138 0> max <integer_cst 0x7ffff702d0f0 65535>>
> QI
> size <integer_cst 0x7ffff702d048 constant 8>
> unit-size <integer_cst 0x7ffff702d060 constant 1>
> ...
>
> where you can see it follows tree -> tree edges up to some depth
> (and avoids repeated expansion). When debugging that's all I have
> and I have to follow edges by matching up the raw addresses printed,
> re-dumping those that didn't get expanded. HTML would be indeed
> so much nicer here (and a more complete output).
I think keeping the current format of what is printed but optionally just
turn all those addresses in there into hyperlinks which would expand the
other trees would be nice. Maybe also allow just hovering on the link and
show the other tree printed might be nice too.
Folding it all into just <function_decl ... bswap <type link> ...>
would mean one can't quickly access just the min/max or fn return type
etc. We might need some parameter how deep to go (and/or how many trees to
dump at most) so that we don't dump into HTML gigabytes of data when asking
to print say a large BIND_EXPR into HTML.
Jakub
