From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by sourceware.org (Postfix) with ESMTPS id 9C09B3858424 for ; Fri, 5 Apr 2024 13:04:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C09B3858424 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 9C09B3858424 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::133 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712322290; cv=none; b=pH/aRCfpbKux+ewjzdlZWXsVA3Il07gvg6Qf7zWAceRMY7y9QgrEHhzKezfxBkMydWh2pCFZN/cDrQwZd06F3A4+3ayW9wmX9PQustUkUXEpYIeZEEw28S21Xc6b5F16HkMopXX0Un4prf7Cyp2mFjDMS7MrOINKe8WEy2zeLFc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712322290; c=relaxed/simple; bh=VOtBdPDVCZOR0ok8VgCqZ+Y8ldDQi8WxSbgx7B5RPvI=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=dsNTh318rwo1otkAUgDS/aPqqVX27VBPwMXHSI/YSuMB+Ss1zkHoTDY0HS4aucsIOYem123xTBaFw2SQWXvIpOfpIeD0Dmr3YxZKm+CD2kvNwYxUVR6ug77Tho57sp1/KsnQc09DqVkA8clKZsT6YwCHmEDeTaVQKOKmTx+5Ag8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x133.google.com with SMTP id 2adb3069b0e04-516d1ecaf25so1491154e87.2 for ; Fri, 05 Apr 2024 06:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712322286; x=1712927086; darn=gcc.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KbhsRf9+akdZN7Vc2Q3s2FxIdNWxW1c1AO/IdZTE8WA=; b=HtWTsvzRtihOOy69zmAwzeZw24LME6AOysTOxNxlAVLgfpajSnsc/lGozQGn3kpRQW 10irTeJgjrJn67kV7nB413Dho8QLNUdebK9QTzbqbHCdgSw/QwpdgiLf8YatVZSyUjr6 /z+WAtDrJm6Ok2lWix3XhjV4ZT1mlQZcLECXU4Xa2kZAWZos1yLKXvxRctWM6pSCKPnV HAv7U+6B7qVHnO/l3WgWln9Aj0F3WKPWtoJHsd3g9Qw4lfIZAu6y/K2+XOgfZBh0MQoY hOxalzuDN+0AW5BLkjYPBqIh56Sx+F52fRqTAejGWKCrs5ac/Z8yo9ml5eAvWayWYbKB /EdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712322286; x=1712927086; h=content-transfer-encoding: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=KbhsRf9+akdZN7Vc2Q3s2FxIdNWxW1c1AO/IdZTE8WA=; b=pwJ3kikWAdjPkYsnYnzTwQcTzXHaGuZ8x6T6lQejkWjDw2rWDYSWNCdcHW3c5LNm5k xk8V+9EvszxGCp/nPmzoFIeIGzheTAwqUXiDkNQLKCZ4/D3QQ5Gi9qYQeuT+5G4ZPL+a f9d54sJzSKFzu9SRyklEohoJNGt6d0H1W4Jb4Ycj4bswK7u0JG2m50hHIXzjpmwq0y6y xn6w8Ip+yoIfqI2D0NX1Luv8EyRFdo9nxNVg3prgnMcZkkdZzp6GpfBlKF11addfF9X0 1Zci+VTbWfx+CmPNTKvJ0d5wLqfU1M/Dvmt/5iP/jzFR7PeTVuWntHtyFBFx74oP7nDn s/Vw== X-Gm-Message-State: AOJu0YyHM1NremEFz3iNGIDG7o98wZ8o0DCwabN+U3OwKEyjjAYMfMmY 9dHp24Jk1038z00gp84E5O1pfRnQD47uocXBO6pp8bz2CRYyc/dtCU6xwJzZbS+GfpN8doOiQUH mHNgmxqSHyBCpOeVQrJmGOh4offc= X-Google-Smtp-Source: AGHT+IESqs+/rwud963EXH1U6SLYJtfdOBb83vrxpuE1isxp+NaKm4fZQyve3yq4zUyOjjU2LenPQXxSVPyRh0nWmWc= X-Received: by 2002:a19:ca01:0:b0:516:d31d:65eb with SMTP id a1-20020a19ca01000000b00516d31d65ebmr917072lfg.14.1712322285845; Fri, 05 Apr 2024 06:04:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Fri, 5 Apr 2024 15:04:34 +0200 Message-ID: Subject: Re: [GSoC] Application RFC + Question - GENERIC dump To: Thor Preimesberger Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: 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-pret= ty-print.cc > > > That's what you get when calling 'debug_tree ()' from the infer= ior 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 const= ants, > 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 applicati= ons > > > > over the holiday. I'm interested in the "Implement structured dumpi= ng > > > > 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 understand= ing > > > 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 fo= rmat like > > > JSON would allow targeting graphviz as postprocessing. > > > > > > > Best, > > > > Thor Preimesberger > > > > > > > > -------------------------------- > > > > > > > > > > > > Background: > > > > > > > > I'm an undergraduate student in pure mathematics who tinkers wi= th > > > > 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 coupl= e > > > > 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 direc= tly > > > > 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 appea= l. > > > > 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 du= mp > > > > option (-fdump-generic-nodes) for the GENERIC intermediate > > > > representation that preserves it's tree structure before it is lowe= red > > > > 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 ne= ed > > > > 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 te= sts > > > > 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 read= ing > > > > 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=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 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 w= ith 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-pret= ty-print.cc > > > That's what you get when calling 'debug_tree ()' from the infer= ior 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.