Re: [GSoC] Application RFC + Question - GENERIC dump

[Richard Biener <richard.guenther@gmail.com>]

On Mon, Apr 1, 2024 at 6:23 PM Thor Preimesberger via Gcc
<gcc@gcc.gnu.org> wrote:
>
> Hey all,
>
>     I'm joining the group of people submitting their GSoC applications
> over the holiday. I'm interested in the "Implement structured dumping
> of GENERIC" project idea, and the application I've written is below.

Thank you for the interest in this project.

>     A quick question before though:
>
>     - What would the expected use cases of the proposed
> -fdump-generic-nodes option be, in addition to, presumably, writing
> front ends into gcc?

I think the main use case is better "visual" debugging and understanding
of GENERIC.  Then a structured dumping would also allow to custom
processing like doing memory or other statistics.

>    I'm also curious about also targeting .gz/Graphviz; on a first
> blush, it doesn't seem like too much additional work, and it may be
> useful for the above applications. But I imagine there may be other
> ways to process the data that would ultimately be more useful.

Reading your message top-down I think that dumping in a structured format like
JSON would allow targeting graphviz as postprocessing.

> Best,
> Thor Preimesberger
>
> --------------------------------
>
>
> Background:
>
>     I'm an undergraduate student in pure mathematics who tinkers with
> technology in his free time. I've taken an interest in compilers as of
> last summer. I've written a couple of parsers, by hand, and a couple
> of toy passes in LLVM. I'm currently working through the code
> generation parts of the Dragon Book, in between my current course
> work. I'm familiar with C and C++, and I'm currently taking courses
> (on quantum information science, digital design, and computer
> architecture) that focus on topics adjacent or tertiary to compiler
> engineering.
>     In the mathematical part of my life, I mostly concentrate on
> geometric analysis, and I've taken a few post graduate courses, on
> Ricci flow and on variational/geometric partial differential
> equations. These topics don't really capture all the mathematics I'm
> interested in, and I don't think any of this academic work is directly
> relevant to this project. But I hope that it conveys that I enjoy
> deep, technical work that interpolates between multiple levels of
> abstraction.
>     I believe compiler engineering shares this same aesthetic appeal.
> This - and the pragmatic, altruistic nature of compiler engineering -
> draws me to the field and to GCC in particular.
>
>
> Expected Outcome:
>     - A patch in the main GCC repository that adds an additional dump
> option (-fdump-generic-nodes) for the GENERIC intermediate
> representation that preserves it's tree structure before it is lowered
> to GIMPLE. We want to initially target JSON, and then provide a
> human-readable translation into HTML.
>
>     Additional features/visualizations are possible, but I would need
> to discuss them with the mentor, Richard Biener.
>
> Timeline:
>
> Pre-GSoC
>
>     I've already built gcc, with and without offloading, and have
> successfully passed the tests under make-gcc. (Well, most of the tests
> for the version of GCC with offloading - I understand that that is to
> be expected.) I'm currently compiling some nontrivial programs to
> various stages of completion, and toying with them in GDB and with
> debug options.
>
>     After this, I want to better understand the architecture of GCC
> and it's intermediate representations. I would achieve this by reading
> the documentation and dumping lots of code.
>
>     Contemporaneously, I would want to at least understand, if not
> possibly fix, a few items/bugs in the GCC Bugzilla. Here are two I
> want to look at, picked wholly by individual interest:
>
>         - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38833
>         - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97444
>
>     (I'm happy to take a look at any issues anyone recommends -
> especially if they are more germane to the project than the above!)

I don't remember any particular bugs around dumping of GENERIC but
there are bugs tagged with the easyhack keyword.

Personally I find memory-hog and compile-time hog issues rewarding
to fix and at times interesting to understand (tiny) bits of GCC very
well.

> GSoC (Starting the week of May 27th, to August 26th)
>
> Community Bonding
>
> Understand the previously submitted patch in (
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646295.html )
> Understand all the intended uses of the project
> Scope out possible augmentations and begin researching them to the
> project after discussing with mentor.
> Continue patching effort, if it's not finished.
>
>
> Weeks 1-4
> Begin working on minimal viable product (GENERIC to JSON, and JSON to HTML)
> Finish scoping possible augmentations by week 4,
> Begin development on any augmentations once approval is obtained
>
> Weeks 4 - 8
> Continue working on minimal viable product
>
> Weeks 8 - 13
> Complete minimal viable product if it is not finished.
> Otherwise, begin working on possible augmentations as agreed upon with mentor
> Wrap up documentation for any unfinished pieces

This looks like a reasonable timeline and overall project structure.  I probably
pointed to it in my responses to the initial patch but to repeat here
it would be
very nice to integrate with the existing GENERIC dumping in tree-pretty-print.cc
That's what you get when calling 'debug_tree (<node>)' from the inferior inside
gdb.  Implementation-wise the JSON target would then be a new
dump flag (see the various TDF_* in dumpfiles.h).

Note the deadline for uploading a proposal is today, please make sure
to upload early,
I think you can always amend the proposal later.

Richard.