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

[Thor Preimesberger <tcpreimesberger@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 11945 bytes --]

Hey all,

I just checked, and it does appear to be the case that proposals can't be
updated anymore.

I do agree with all the proposed amendments (and would pick to move JSON to
HTML), and I'll double-check to see if there's a way to push them into the
application.

I'm on JST for right now, if my emails are coming in at a weird time.

Thanks!
Thor



On Fri, Apr 5, 2024, 11:27 PM Martin Jambor <mjambor@suse.cz> wrote:

> Hello,
>
> On Fri, Apr 05 2024, Richard Biener via Gcc wrote:
> > On Tue, Apr 2, 2024 at 1:16 PM Richard Biener
> > <richard.guenther@gmail.com> wrote:
> >>
> >> On Tue, Apr 2, 2024 at 11:14 AM Thor Preimesberger via Gcc
> >> <gcc@gcc.gnu.org> wrote:
> >> >
> >> > Forgot to CC the mailing list - mea culpa.
> >> >
> >> > ---------- Forwarded message ---------
> >> > From: Thor Preimesberger <tcpreimesberger@gmail.com>
> >> > Date: Tue, Apr 2, 2024 at 5:57 PM
> >> > Subject: Re: [GSoC] Application RFC + Question - GENERIC dump
> >> > To: Richard Biener <richard.guenther@gmail.com>
> >> >
> >> >
> >> > Thanks for the quick feedback, especially on such short notice - I'll
> >> > get the actual GSoC application in, within a couple of hours.
> >> >
> >> > > 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).
> >> >
> >> > Understood - To check my understanding, is it correct to say that we
> >> > essentially want to parse the output of tree-pretty-print.cc into
> >> > JSON?
> >>
> >> No, we want to emit JSON directly from tree-pretty-print.cc conditional
> >> of the new dump flag.
> >
> > Thanks for uploading the proposal.  Can you please update it to remove
> > the confusion around "parsing of the tree-pretty-print.cc output"?
>
> IIUC proposals cannot be altered past the Tuesday deadline.  Still, they
> probably can clarified somewhat here even in the upcoming days (but
> really not much more than that), so that all involved parties are then
> not surprised if the project needs to take a slightly different
> direction (assuming it will be selected AND we get enough slots in the
> program from Google).
>
> Thanks,
>
> Martin
>
>
> > As
> > said we instead want to emit JSON directly from the GENERIC
> representation
> > as it is in memory, preferably as an output variant to the existing
> > tree-pretty-print.cc output to make it easy to keep both variants in
> sync.
> >
> > As for the timeline and way of development I would strongly suggest to
> > develop the JSON -> html (or JSON -> graphviz if you like that more)
> > translator in parallel to be able to incrementally verify the user
> consumed
> > output is as desired.  Unimplemented JSON bits can be always
> > implemented as text JSON nodes containing the textual
> tree-pretty-print.cc
> > output.
> >
> > One of the important goals is to have the JSON output functionality
> > in tree-pretty-print.cc implemented in a maintainable way, making it
> > easy to adjust JSON/non-JSON output when the data structures change.
> >
> > Thanks,
> > Richard.
> >
> >> > Then, this parser then would be used in a new dump pass, from
> >> > either inside gdb or from gcc itself, to dump the JSON wherever it
> >> > needs to go.
> >>
> >> For the actual -fdump-generic-nodes we would call the dumper with the
> >> new flag and likely have set up the output to a file.
> >>
> >> > So ultimately the idea is to create both the parser and a new dump
> pass from it.
> >>
> >> I don't think there's a parser involved, in the end we'd have to
> >> "parse" the JSON
> >> to produce HTML or graphviz output, but the JSON emission would be from
> >> inside dump_generic_node (and sibliings), conditional on the dump
> flag.  Note
> >> that a lot of things will be dumped the same such as identifiers or
> constants,
> >> but all structured bits would be different.
> >>
> >> Richard.
> >>
> >> > I just read the notes you gave on the original patch. I'll edit the
> >> > plan a bit to emphasize interworking with tree-pretty-print, and
> >> > checking the bugs that mention easyhack.
> >> >
> >> > Best,
> >> > Thor Preimesberger
> >> >
> >> >
> >> > On Tue, Apr 2, 2024 at 4:20 PM Richard Biener
> >> > <richard.guenther@gmail.com> wrote:
> >> > >
> >> > > 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.
>