From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2a07:de40:b251:101:10:150:64:2]) by sourceware.org (Postfix) with ESMTPS id 83EF43858C98 for ; Fri, 5 Apr 2024 14:27:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 83EF43858C98 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.cz ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 83EF43858C98 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:2 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712327244; cv=none; b=dKzkqYl6JqF3ccHWbJWFjVaPa0wijLlh32YaDrxX45mcFfVARleYo5WKvNHoe8MBNOc3dm46Ncim6wSJlOAIfy+0MJ4wKgGU+dNiao+49m1QQv3KGeyO2PjFRke8n2R1Dz2tXU6zvyt7SY3zxZwfDJS/aMGsLFfWZL25jTdQEkE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712327244; c=relaxed/simple; bh=tKMZK1e2Jo9mJ0ENlgcWlnN6zVxkrUmwSf+a9bdSNJY=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature:From: To:Subject:Date:Message-ID:MIME-Version; b=FHB2pVNun4vbVvLwm5IKSpCx0W1z4aXo8mTm+0g0SylgcydVLDUsO84mdTls8nhjRhMVcnEZjJru6vTE9laEBdAF1msMySpLvSvEv1StzZcc+wqmGlVNGn8WUS+B1gFm9s2u55uM7DKFJLnXffhOi6oBIKqL81w5cC72EQRDKAY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from imap2.dmz-prg2.suse.org (imap2.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 638031F7D7; Fri, 5 Apr 2024 14:27:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1712327239; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rY8Nx9ioDzk4XE5VKNNnYBC8ze4cKPsTk/nqjZZpi/I=; b=Z0uElY8vG4fuHfIT7vTqFZqkoZEBrvsyPRsGo+PrLAAKqYbAGUozz9NhQ8RjisCvq7duSI qhBWk77pSWhHVKmAcq/AMuB+PSzpRCsaclr1JY+hCA4rZa9nDE8g7BKbrhFm2IL8QuGTb2 Jjt0pLpKOBJwJYZnWQnfe3uu19iCzng= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1712327239; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rY8Nx9ioDzk4XE5VKNNnYBC8ze4cKPsTk/nqjZZpi/I=; b=jyileRmQIIjC79XtrgqgjObms1NZahvCSO8RqPfTE95pXLcVEBn5w4TMKShYPRuMmT7YyW vAw1hcwziLpwbiDQ== Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Z0uElY8v; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=jyileRmQ DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1712327239; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rY8Nx9ioDzk4XE5VKNNnYBC8ze4cKPsTk/nqjZZpi/I=; b=Z0uElY8vG4fuHfIT7vTqFZqkoZEBrvsyPRsGo+PrLAAKqYbAGUozz9NhQ8RjisCvq7duSI qhBWk77pSWhHVKmAcq/AMuB+PSzpRCsaclr1JY+hCA4rZa9nDE8g7BKbrhFm2IL8QuGTb2 Jjt0pLpKOBJwJYZnWQnfe3uu19iCzng= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1712327239; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rY8Nx9ioDzk4XE5VKNNnYBC8ze4cKPsTk/nqjZZpi/I=; b=jyileRmQIIjC79XtrgqgjObms1NZahvCSO8RqPfTE95pXLcVEBn5w4TMKShYPRuMmT7YyW vAw1hcwziLpwbiDQ== Received: from imap2.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap2.dmz-prg2.suse.org (Postfix) with ESMTPS id 5C39B139E8; Fri, 5 Apr 2024 14:27:19 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap2.dmz-prg2.suse.org with ESMTPSA id 76mCFkcKEGZrRAAAn2gu4w (envelope-from ); Fri, 05 Apr 2024 14:27:19 +0000 From: Martin Jambor To: Richard Biener , Thor Preimesberger Cc: gcc@gcc.gnu.org Subject: Re: [GSoC] Application RFC + Question - GENERIC dump In-Reply-To: References: User-Agent: Notmuch/0.38.2 (https://notmuchmail.org) Emacs/29.3 (x86_64-suse-linux-gnu) Date: Fri, 05 Apr 2024 16:27:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Level: X-Spamd-Result: default: False [-4.51 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MX_GOOD(-0.01)[]; TAGGED_RCPT(0.00)[]; TO_DN_SOME(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; FUZZY_BLOCKED(0.00)[rspamd.com]; RCPT_COUNT_THREE(0.00)[3]; RCVD_TLS_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap2.dmz-prg2.suse.org:helo,imap2.dmz-prg2.suse.org:rdns,gnu.org:url,gnu.org:email]; DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519]; DKIM_TRACE(0.00)[suse.cz:+] X-Rspamd-Action: no action X-Rspamd-Queue-Id: 638031F7D7 X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Score: -4.51 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,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: 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-pre= tty-print.cc >> > > That's what you get when calling 'debug_tree ()' from the infe= rior 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 consum= ed > 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 pas= s 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 cons= tants, >> 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 applicat= ions >> > > > over the holiday. I'm interested in the "Implement structured dump= ing >> > > > of GENERIC" project idea, and the application I've written is belo= w. >> > > >> > > 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 understan= ding >> > > 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 f= ormat like >> > > JSON would allow targeting graphviz as postprocessing. >> > > >> > > > Best, >> > > > Thor Preimesberger >> > > > >> > > > -------------------------------- >> > > > >> > > > >> > > > Background: >> > > > >> > > > I'm an undergraduate student in pure mathematics who tinkers w= ith >> > > > technology in his free time. I've taken an interest in compilers a= s of >> > > > last summer. I've written a couple of parsers, by hand, and a coup= le >> > > > 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 dire= ctly >> > > > 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 appe= al. >> > > > This - and the pragmatic, altruistic nature of compiler engineerin= g - >> > > > draws me to the field and to GCC in particular. >> > > > >> > > > >> > > > Expected Outcome: >> > > > - A patch in the main GCC repository that adds an additional d= ump >> > > > option (-fdump-generic-nodes) for the GENERIC intermediate >> > > > representation that preserves it's tree structure before it is low= ered >> > > > 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 n= eed >> > > > 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 t= ests >> > > > 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 rea= ding >> > > > 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.htm= l ) >> > > > 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 >> > > >> > > 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-pre= tty-print.cc >> > > That's what you get when calling 'debug_tree ()' from the infe= rior 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.