[GSoC] Application RFC + Question - GENERIC dump

[GSoC] Application RFC + Question - GENERIC dump

[Thor Preimesberger]

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.

    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'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.

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!)

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

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

[Richard Biener]

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.

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

[Thor Preimesberger]

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? 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.

So ultimately the idea is to create both the parser and a new dump pass from it.

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.

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

[Richard Biener]

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.

> 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.

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

[Richard Biener]

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"?  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.

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

[Martin Jambor]

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.

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

[Thor Preimesberger]

[-- 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.
>