From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 697523858D39 for ; Tue, 2 Apr 2024 11:16:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 697523858D39 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 697523858D39 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::22f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712056614; cv=none; b=YeahMiKaEx3bGSIjM+zEz0NLuXjnzSx7c7IVKY9w/v+jLiPsduG9n0Jl7oPUCbmOucivSVgNkZRV2WGO1NFKhCwPGvWpscH8K6lP4MgH37HxoY6IEKoXRqKUyxyzNJvUurPnc+0br4jbOz2aR2+Xsgk1j6EQBeflvOvaIRDXNFo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712056614; c=relaxed/simple; bh=CBU1TvqG79fHzKUBXSfK6wy0UZQ6uYv8cOlbkful33Y=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=CZIyBZ6h9V/z4Ok3zm5bDbtYQ1wxzbuBr/Apx7BhwQUhipUQTm21BGUZHQzO/3lCYHIg/k4zzi59DZDXvYSIsetQzFnO6XKCK5YMvKgBcEEq/RTJLtKF83Zuehknmge/YOjPDYAXEo+Si+5As5IxfOWYU0MhcG18S3O93BQqWL0= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2d687da75c4so49364491fa.0 for ; Tue, 02 Apr 2024 04:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712056606; x=1712661406; 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=bt84kqmJ+i0dgnTwLij6dhAKhLCyJnYExr1h1V+ZnrU=; b=XOD2hHleBUUmXdiucOT5F5lIasGH3dOErF7LyQXY/YCEZf2gNvqMi6nwRkY+nZmYJs w2o5mN7J9q/k5oq7FHEBFFgd8u5bRoH5L30Hit2w+cCCqrMi/Bj6BzzqAImSNg23hSS4 6+Oz/19VSXC3dbHDdd/heXEt8pZTxNg9db2SxZ2725nvv0zn3sANm9TB9gVCXCcRgx/9 7NHgUeU90bIALqFNtH1BxZhqVEtxLe5q5o3jr4j+TN9R8dXyFKGMM27HkD39MfYH36EO AnDUJ2dqBOEQtfxltLH+yM+4/7682YuP2Q8vkp9nd/0kFjpR45KWeO1xr6R8533wfux3 tdsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712056606; x=1712661406; 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=bt84kqmJ+i0dgnTwLij6dhAKhLCyJnYExr1h1V+ZnrU=; b=uU5l2CjVc64AcJCpZy8XnER+5+KgsmmlAau2CS8631uoTdDVjdBUswRjJhFMn4s88l ++BqMvUbC+YTDj0E5+oIySUQsbfuf28G67Z3/JXiohtapFmPw/uMV2zQPBnCEDV7adC3 Mz3WnGPEVOLQcqYfoOY4Qz+QZdrlVgVB0zaDH2a4W4Ki2mx5IG3dvW2RlHZXlrLDPUAw WGr9lAzGUUMAZ40hpPwz8FOYP127kRGPCXiKWpuXjgxhnQtBLrY6m1haU056eX3mUfOU fTa4XMyggFszhKD6NB6lNzJmLmN1Jbx5a6cef2DsBpIdX0MCweullysSaXw5Elfjoe4c aOtQ== X-Gm-Message-State: AOJu0Ywh4CZmnwtMpCs1PktrN/K/iaM53cc39ldKVNPPggd7MHYGWlb+ /U4gO/wqznhaX+P9FM0eh8SCO5XrEGHojdlugp3Vp7x8uuYqUYPdIoCUX7VpK7lMXsC6VaKLQzS WGoyM9FwYZ7pp6TrmVIDglzPMXuk= X-Google-Smtp-Source: AGHT+IHfhr1FfVnjxcUGHlokUmHKQ7kJcljpDRIdsNxGR7+LFjccJqaMIkQSaj0ZX76qHjyynB3zaZ4DJllFmTyqRVQ= X-Received: by 2002:a2e:a60c:0:b0:2d4:b061:da01 with SMTP id v12-20020a2ea60c000000b002d4b061da01mr6024200ljp.19.1712056605419; Tue, 02 Apr 2024 04:16:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Tue, 2 Apr 2024 13:16: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.8 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 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 inferio= r 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 f= rom 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. No= te that a lot of things will be dumped the same such as identifiers or constan= ts, 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 application= s > > > 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 understandin= g > > 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 form= at 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 o= f > > > 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 directl= y > > > 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 lowere= d > > > 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 test= s > > > 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 readin= g > > > 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 wit= h 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 inferio= r 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.