public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thor Preimesberger <tcpreimesberger@gmail.com>
To: gcc@gcc.gnu.org
Subject: [GSoC] Application RFC + Question - GENERIC dump
Date: Tue, 2 Apr 2024 01:21:41 +0900	[thread overview]
Message-ID: <CAKsitGbdEqkC6B4vqX1q2brUS+-yyNBifjnNp1dVPMyNzXpTiw@mail.gmail.com> (raw)

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

             reply	other threads:[~2024-04-01 16:21 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-01 16:21 Thor Preimesberger [this message]
2024-04-02  7:20 ` Richard Biener
     [not found]   ` <CAKsitGbgcE+P3aWJ0juKRd6dwfFLSinAAKYue--_uxEtFdJqzg@mail.gmail.com>
2024-04-02  9:12     ` Fwd: " Thor Preimesberger
2024-04-02 11:16       ` Richard Biener
2024-04-05 13:04         ` Richard Biener
2024-04-05 14:27           ` Martin Jambor
2024-04-05 21:10             ` Thor Preimesberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKsitGbdEqkC6B4vqX1q2brUS+-yyNBifjnNp1dVPMyNzXpTiw@mail.gmail.com \
    --to=tcpreimesberger@gmail.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).