From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id 04B193858D28 for ; Tue, 2 Apr 2024 07:20:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 04B193858D28 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 04B193858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::22b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712042425; cv=none; b=mtm5sqvGOUJqJpZxUsBZxdReAtQDUViNaBEDWUbAA8NmQZ1KUBZxWZzVu9iJbp2moUJXyIeuDVhx2M96jC6D8DBdR6Yd5CDpAhkfuXpBCVgdd+yESOiK5dP686qkZvtw3g03a70sBlCWGsQbfYyddJ1yIICWRcyjtQf/YvDOHAE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712042425; c=relaxed/simple; bh=bTl2dy1BmNzocluZPNwnrV7hxs6DRgZGYLwJIpfPslg=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=esuHUN8oCvhwR9X/zSQNruOPxzAs26EY+ypvU2ATRa31N/ndrNdc9gf1C781d19egKxD+O3UsUa8c3ixNdCeaZq3TodeHQfhUhKu81QJ7wCgQE/G8Gkpru0nvOMP9IWMyxc75lnLmVpBpB/kaqxBxlEHN6SlABqmXH0wKzfHiZA= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2d4a8bddc21so66969741fa.0 for ; Tue, 02 Apr 2024 00:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712042421; x=1712647221; 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=xa7CKiFZAflu8SePZJ4EhJoQhcxGVTNmQdA+VkUwU/0=; b=V5zMoVauNLvonvah7Wc4mWNNcwezVOaTiLmlAC4xPXbXABEV4ebp6Hkk6hSWkgm6qQ 6k/2us9Y62qy4u0WNUUYjtiwA+E6S+u/P/i99w3W+9Cw+nBDzo1fe882Sg9nzIRI3VqZ gx05HMeEOAE0xj5uJ3uje6h7Na4DR7xyP63Molt5h9fCD/ijSNoBPsRFvfavb3BU31UV YrbLhddDXHB+V/kKT52KRKBolLUyIO7hgX81vIJo6U/MlVeYDpvV8n8Ju4qtfu9taUUD xL27njXIok1ETCGH0TVWQRu/KzTDq3RiKz0uVgGJ1hbDXIUbsYfxGuKot/WEKer6cZU2 QKJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712042421; x=1712647221; 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=xa7CKiFZAflu8SePZJ4EhJoQhcxGVTNmQdA+VkUwU/0=; b=P1GxlxmX2/7HzXiOTc6+px7YPHcLTaBTjzUPr7MQTpv9lEi+vSa5WR5LDchgZ5igBe 20j6MVIZjJRZykJ3jGXuXI5iLbtQgJj2z2hQg3Ur72FEmLB8Qe2U5ukmPer9M0npMHqe VecThWlvvOQJA9Byt0HnqlLSvB5f40dxiGYZjqLI5BwMD93AGr/ERZh8203L1pLjVulj kqoOk/AZUqhYp+WIuhv1391njgSL+x9IH5ajWn276g9aaRzPm4JG3tSvi1fnoldEOdVc Fzuahi4wSiH7NiJNSr5oV3xr/mTUTxnlaLJFRdnHEaunLemb51r22PvFIOw0+gxwjO8L OZiQ== X-Gm-Message-State: AOJu0YyqiUGTONBzILKVVybNxYmTVn34GEC/JVfBEGmkrhZfUIJv4fV0 iNrh1gSy1HpxPgQgDSBgvEUJAOrNxRBXT86LGNkcLV9q/oSFY6tcIvJSYJQ7gdTHzFABC8cW0fU fN4kvVa8/RrdhfKjxvVPLaLrOpVSfIgJ/ X-Google-Smtp-Source: AGHT+IEFCEpwmW0af+dxmOGmJmFHg1yxIcXF1jC5QScb1LVNWckE9I0HWpFNpF9UBMrrYLJ9f32biQv7fpWApx5HS/4= X-Received: by 2002:a2e:bea7:0:b0:2d8:2f68:778c with SMTP id a39-20020a2ebea7000000b002d82f68778cmr331882ljr.4.1712042421263; Tue, 02 Apr 2024 00:20:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Tue, 2 Apr 2024 09:20:10 +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.4 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 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 l= ike 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=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 HTM= L) > 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 me= ntor > Wrap up documentation for any unfinished pieces This looks like a reasonable timeline and overall project structure. I pro= bably 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-pri= nt.cc That's what you get when calling 'debug_tree ()' from the inferior in= side 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.