From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id 2D34C3858D34 for ; Fri, 5 Apr 2024 21:10:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2D34C3858D34 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2D34C3858D34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::32f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712351453; cv=none; b=BUiXmFqCPPHP2PqEwYuOIus1NsmEc80bseLwV/QaTcgb0ZX5kNIv3tCywg8eOuRQ4+w+zlmbdXyoRiOFx8BS4/Ti6po52EgQ/70Dobbb0mkb21s9lvUoRWzTQx74X4H8fRg+liwAdld9Ir4AwkuHREVlzmi0I4Jxqel6jJHpFck= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712351453; c=relaxed/simple; bh=/+bhLhObg//7iB9FjP0vB4M3PvP63MbJBknuaSZdEIk=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=QT9V+YOxV7T6ly3Un0FzmQJvh4A4IDVMgnKZrDPWe8ha42DL8ycJCPAnGtQM7zgj4eNT5cdU5g+c4USlaDDxak/L8ljo6bGCmAQtvyOk7p1SKTns6X/GgeO5VBgzZ1NorIZvdrBX4FNPPkRrd89T3TcjQfVwzm/LfAhEWErjFDM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4162b5ba2bbso16006615e9.1 for ; Fri, 05 Apr 2024 14:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712351448; x=1712956248; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Iz8yANKkjvIeI4ihCh9M/q3nZGoRGdMt0G1R5V1B4d0=; b=eTRw8F6XPZfHK92QOI4RLpVBPNA6IAkvyvLOp89DbbppTSibQMwY6neBnrqKiuv0bq BRZxn0QLPJQnj0LEb7rOU+M1HfjD+YLcreRiYSuNxIL0G1NaXcj+H49dntkBva5xyzgx vRzn5LLywFMM4Wkbwjaxd+rOAPS0o2sgO9+cXHQRHhuEaoxhCwKdaq3AwUPQofe8Wfrj qKMuvWVBa55ehmzgTu82nc1gLbMcswXeBFE8gRkSJ/OpPYp4Ni/ba4Jhry8oDel2Ub4C 0wCkWnbxo+AtT0CrQvuiCFvBetV4MRA98d1jAZOXWvXosWGdUtJdDuI11hzbYdUeYaTX hFmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712351448; x=1712956248; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Iz8yANKkjvIeI4ihCh9M/q3nZGoRGdMt0G1R5V1B4d0=; b=EdGhkKSS6SOPn9xN2hGm/tJdcjnOvwzusXf3zJToPaMgex1CGuMDTur4g4obERFo7r tzsEMloIyzXqXpw6dyM8XPHsYoNJeeV/qXPnyBiltGMmoaevVIz09IgOK4tttw8dpixj GfXFaG9/nga6VP5SluQSxuuwHBoWGjRVfpDF4RVxfz1DRrzAx2AaMXy+L8B93UAuSmNd F4/I8r6hhCLYiRJWXvt076kZsKzHeKc8JjpI6VbEoD0cBJDkLoHZ+TMPupeKC8QlbCJr ik0ztlSR3S3TeYrp2nlmT9sSZaknFVFrPOYKgwc/TvwcF92HdR2FzGSSDUgWhdgz0Ox8 mxPg== X-Gm-Message-State: AOJu0Yya9D3kh6LoJh4Qar3KVV+j9Q1t2WSBIZzgy/z+ayRlH+0t/wQF gEgEpjSjRSc14XOlc0FcB+LM8kSWSW7FO+nhGxF5CuNymbSWtmvJ4Hg8I8cwaBhiDEgBw1PSQMu QqvLIGBU5+HpWQnNh9fQlvpmHCyM= X-Google-Smtp-Source: AGHT+IGO97E3bZicAIfExo5UXa3ixzTxlsUMdb6NGFVIEYOHeaHWZdYX9rjRVCYsc4URE7JgPxqFY0+zehfRauxYBNI= X-Received: by 2002:adf:a4db:0:b0:343:3e5b:e8af with SMTP id h27-20020adfa4db000000b003433e5be8afmr2373111wrb.52.1712351447534; Fri, 05 Apr 2024 14:10:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Thor Preimesberger Date: Sat, 6 Apr 2024 06:10:34 +0900 Message-ID: Subject: Re: [GSoC] Application RFC + Question - GENERIC dump To: Martin Jambor , Richard Biener Cc: gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000c2d58206155fe35d" X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000c2d58206155fe35d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM Martin Jambor wrote: > Hello, > > On Fri, Apr 05 2024, Richard Biener via Gcc wrote: > > On Tue, Apr 2, 2024 at 1:16=E2=80=AFPM Richard Biener > > wrote: > >> > >> On Tue, Apr 2, 2024 at 11:14=E2=80=AFAM Thor Preimesberger via Gcc > >> wrote: > >> > > >> > Forgot to CC the mailing list - mea culpa. > >> > > >> > ---------- Forwarded message --------- > >> > From: Thor Preimesberger > >> > Date: Tue, Apr 2, 2024 at 5:57=E2=80=AFPM > >> > Subject: Re: [GSoC] Application RFC + Question - GENERIC dump > >> > To: Richard Biener > >> > > >> > > >> > 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 ()' 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=E2=80=AFPM Richard Biener > >> > wrote: > >> > > > >> > > On Mon, Apr 1, 2024 at 6:23=E2=80=AFPM Thor Preimesberger via Gcc > >> > > 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 wi= th > >> > > > 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 n= ot > >> > > > 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=3D38833 > >> > > > - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D97444 > >> > > > > >> > > > (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 t= he > >> > > > 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 ()' 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. > --000000000000c2d58206155fe35d--