From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id B60233858C31 for ; Thu, 29 Feb 2024 07:33:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B60233858C31 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 B60233858C31 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::12a ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709192024; cv=none; b=CuBUHcG+b1dbfwa+KKhvb6Fe37cf8D60OC7XBaD/D3A2OBfPGYc1iTXOs5IZSTfRB+HLPpxNTFJ5p/6pXykWUgB7Dh2ol8n/1JQtpKzrptYNefRLNTE77nrUWDbGxl9sAJpwom0SmR4mJcgKRECrqmG+RG0+tT8MEHBGZYzh060= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709192024; c=relaxed/simple; bh=DWLAPnND5v6uhxzQyCieJY2xmkzNfFOueymIwY5X3vw=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=TzVla79GUDWq40FOH7BvycYaRRXzS3HfuI0jihDcjOL7yiokpZ3VH8WEFMe3dYzPHaXwmp4sQEzYH2zSHxQMDyZ3phAOHoE/CV3J7W81xHrvugdht0/HrQY6l9tusZHrj7CXqHXy90Errk47D120lVWfvEehD75hMoZZwFFzOfo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-5132181d54bso600257e87.3 for ; Wed, 28 Feb 2024 23:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709192019; x=1709796819; 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=1mdFWMWw1Jtyj8s2BNV7un43CsQTv1hDwVa38nHBE80=; b=deteShUXmFlQyyfDD0nOvR+XUKfrqeFyq6pGXEjSThCHZK5tR6TTa5mwlU7CwlqQX/ DrGATucWXtRAiPrtPQoQQolETihXL15BZecW9SxrBmdo8oIynIjgCxHieVMGHbsLrEqf NAsh5csfCqfW2YV2JPLSdt25lSwQvakbEt07X6WyDgYAg24iRMekSLBmdBFcXVKXfXHx LmHaXcscpejxGbbHK60xqmU6rduDxG6QwuXKethA8aFBjqtFB7LXY0x4gkqHfq8dqkYg 1rdDgkGc+jp54C5LTpnWI0zeDSwwlWwNeet1r/706d4brgiaoTp7CXoBw5XTWJTiv2h3 HVWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709192019; x=1709796819; 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=1mdFWMWw1Jtyj8s2BNV7un43CsQTv1hDwVa38nHBE80=; b=fLZY4JWAY1fC1LY019oZtfwUUV5e9eApx6ITifexP0YvQx/piRIJS6wfF0vAiyZG1m EHu6BkIaM/AxPVtxLjM/2YcDUOhL4JP8pFe3l9zKRVyp+KRFJ8B4I31tQL63Ti69SddZ s7aMfAKzowja+ehDeOjkM2wAqNpcgbWfhulhfl3/zdssnOo64m8xjjRIFN4/uUfQARmx RW4GyC5TMSxcFhsapPHma7z+ZhMlQQ+FLk9HgQ8Mh0TAsE3MkPdPv6AxDK9+P5yiYnC7 NW67Xeu6jHpbwJQJhIRevOSZp6Bww+M/zJhTsz89HJxYXWH4J0O4ZWBwl6uE0k7/9fnI rs1A== X-Forwarded-Encrypted: i=1; AJvYcCUe+SM3qI8viL5gVigXwx3urFZCV6PW9/iCUgfPqkQOM7fpx3kykE3iHT6Z/eAvKmJN9ydNy4/sShTmKMzk38YV0+Bh0n8bHg== X-Gm-Message-State: AOJu0YzkjGiIfgLT9OBusv/CV483G/j/oq+9byFN4n7tTvfagV/nCDpi DcqAL1CWktg9rF43FT0KAhrcq6zRHcjMBjb3Xiky0TYW5h1EwqtKtiffJr6IhKQeKXiPBY65vjM KVOAIgqtZ3jR6fk7j8GkutsOuG6g= X-Google-Smtp-Source: AGHT+IFNUvDL2+qyYbFmUvN1nC7i488EjmOjIlet8OjONPasGlMceBNQlvs8yC9WPF6utTQzQ4hy+uEyRULDb7k27MU= X-Received: by 2002:a19:2d53:0:b0:513:5d6:66dc with SMTP id t19-20020a192d53000000b0051305d666dcmr621411lft.38.1709192018711; Wed, 28 Feb 2024 23:33:38 -0800 (PST) MIME-Version: 1.0 References: <009401da65ae$8790a750$96b1f5f0$@symas.com> <09de01da69c2$c5f57260$51e05720$@symas.com> In-Reply-To: From: Richard Biener Date: Thu, 29 Feb 2024 08:33:27 +0100 Message-ID: Subject: Re: [PATCH] developer option: -fdump-generic-nodes; initial incorporation To: David Malcolm Cc: Robert Dubner , gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 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,T_SCC_BODY_TEXT_LINE 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 Wed, Feb 28, 2024 at 4:14=E2=80=AFPM David Malcolm = wrote: > > On Wed, 2024-02-28 at 08:58 +0100, Richard Biener wrote: > > On Tue, Feb 27, 2024 at 10:20=E2=80=AFPM Robert Dubner > > wrote: > > > > > > Richard, > > > > > > Thank you very much for your comments. > > > > > > When I set out to create the capability, I had a "specification" in > > > mind. > > > > > > I didn't have a clue how to create a GENERIC tree that could be fed > > > to the > > > middle end in a way that would successfully result in an > > > executable. And I > > > needed to be able to do that in order to proceed with the project > > > of > > > creating a COBOL front end. > > > > > > So, I came up with the idea of using GCC to compile simple > > > programs, and to > > > hook into the compiler to examine the trees fed to the middle end, > > > and to > > > display those trees in the human-readable format I needed to > > > understand > > > them. And that's what I did. > > > > > > My first incarnation generated pure text files, and I used that to > > > get > > > going. > > > > > > After a while I realized that when I used the output file, I was > > > spending a > > > lot of time searching through the text files. And I had the > > > brainstorm! > > > Hyperlinks! HTML files! We have the technology! So, I created > > > the .HTML > > > files as well. > > > > > > I found this useful to the point of necessity in order to learn how > > > to > > > generate the GENERIC trees. I believe it would be equally useful > > > to the > > > next developer who, for whatever reason, needs to understand, on a > > > "You need > > > to learn the alphabet before you can learn how to read" level, what > > > the > > > middle end requires from a GENERIC tree generated by a front end. > > > > > > But I've never used it on a complex program. I've used it only to > > > learn how > > > to create the GENERIC nodes for very particular things, and so I > > > would use > > > the -fdump-generic-nodes feature on a very simple C program that > > > demonstrated, in isolation, the feature I needed. Once I figured > > > it out, I > > > would create front end C routines or macros that used the > > > tree.h/tree.cc > > > features to build those GENERIC trees, and then I would move on. > > > > > > I decided to offer it up here, in order to to learn how to create > > > patches > > > and to get > > > to know the people and the process, as well as from the desire to > > > share it. > > > And instantly I got the "How about a machine-readable format?" > > > comments. > > > Which are reasonable. So, because it wasn't hard, I hacked at the > > > existing > > > code to create a JSON output. (But I remind you that up until now, > > > nobody > > > seems to have needed a JSON representation.) > > > > > > And your observation that the human readable representation could > > > be made > > > from the JSON representation is totally accurate. > > > > > > But that wasn't my specification. My specification was "A tool so > > > that a > > > human being can examine a simple GENERIC tree to learn how it's > > > done." > > > > > > But it seems to me that we are now moving into the realm of a new > > > specification. > > > > > > Said another way: To go from "A human readable representation of a > > > simple > > > GENERIC tree" to "A machine readable JSON representation of an > > > arbitrarily > > > complex GENERIC tree, from which a human readable representation > > > can be > > > created" means, in effect, starting over on a different project > > > that I don't > > > need. I already *have* a project that I am working on -- the COBOL > > > front > > > end. > > > > > > The complexity of GENERIC trees is, in my experienced opinion, an > > > obstacle > > > for the creation of front ends. The GCC Internals document has a > > > lot of > > > information, but to go from it to a front end is like using the > > > maintenance > > > manual for an F16 fighter to try to learn to fly the aircraft. > > > > > > The program "main(){}" generates a tree with over seventy nodes. I > > > see no > > > way to document why that's true; it's all arbitrary in the sense > > > that "this > > > is how GCC works". -fdump-generic-nodes made it possible for me to > > > figure > > > out how those nodes are connected and, thus, how to create a new > > > front end. > > > I figure that other developers might find it useful, as well. > > > > > > I guess I am saying that I am not, at this time, able to work on a > > > whole > > > different tool. I think what I have done so far does something > > > useful that > > > doesn't seem to otherwise exist in GCC. > > > > > > I suppose the question for you is, "Is it useful enough?" > > > > > > I won't be offended if the answer is "No" and I hope you won't be > > > offended > > > by my not having the bandwidth to address your very thoughtful and > > > valid > > > observations about how it could be better. > > > > No offense taken - I did realize how useful this was to you (and > > specifically > > the hyper-linking looked even very useful to me!). I often lament > > the lack > > of domain-specific visualization tools for the various data > > structures GCC > > has - having something for GENERIC would be very welcome. > > > > We have for example ways to dump graphviz .dot format graphs of the > > CFG > > and some other data structures and do that natively, not via JSON > > indirection. > > FWIW for GCC 15 I've been experimenting with adding a > text_art::tree_widget class; with that, the analyzer can visualize an > ana::program_state instance like this (potentially with colorization in > suitable terminals): > > State > =E2=94=9C=E2=94=80 Region Model > =E2=94=82 =E2=94=9C=E2=94=80 Current Frame: frame: =E2=80=98test_7=E2=80= =99@1 > =E2=94=82 =E2=94=9C=E2=94=80 Store > =E2=94=82 =E2=94=82 =E2=95=B0=E2=94=80 root region > =E2=94=82 =E2=94=82 =E2=95=B0=E2=94=80 (*INIT_VAL(a_10(D))) > =E2=94=82 =E2=94=82 =E2=95=B0=E2=94=80 bytes 12-15: =E2=80=98int= =E2=80=99 {(int)42} > =E2=94=82 =E2=95=B0=E2=94=80 Constraints > =E2=94=82 =E2=94=9C=E2=94=80 Equivalence class ec0 > =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80 (void *)0B > =E2=94=82 =E2=94=82 =E2=95=B0=E2=94=80 =E2=80=980B=E2=80=99 > =E2=94=82 =E2=94=9C=E2=94=80 Equivalence class ec1 > =E2=94=82 =E2=94=82 =E2=95=B0=E2=94=80 INIT_VAL(a_10(D)) > =E2=94=82 =E2=94=9C=E2=94=80 Equivalence class ec2 > =E2=94=82 =E2=94=82 =E2=95=B0=E2=94=80 (INIT_VAL(a_10(D))+(sizetype)= 12) > =E2=94=82 =E2=94=9C=E2=94=80 ec1: {INIT_VAL(a_10(D))} !=3D ec0: {(voi= d *)0B =3D=3D [m_constant]=E2=80=980B=E2=80=99} > =E2=94=82 =E2=95=B0=E2=94=80 ec2: {(INIT_VAL(a_10(D))+(sizetype)12)} = !=3D ec0: {(void *)0B =3D=3D [m_constant]=E2=80=980B=E2=80=99} > =E2=95=B0=E2=94=80 =E2=80=98malloc=E2=80=99 state machine > =E2=95=B0=E2=94=80 0x62082e0: (INIT_VAL(a_10(D))+(sizetype)12): assume= d-non-null (in frame: =E2=80=98test_7=E2=80=99@1) > > and such visualizations could be added for other hierarchical data > structures. Also, because it uses text_art::widget, the content at a > tree node doesn't have to be purely textual, and we could do things > like the following (which is a mockup): > > State > =E2=94=9C=E2=94=80 Region Model Bound value =E2=94=82 Effective= value > =E2=94=82 =E2=94=9C=E2=94=80 Stack =E2=94=82 > =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80 frame@0 'foo' =E2= =94=82 > =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80 'i' (int)42= =E2=94=82 > =E2=94=82 =E2=94=82 =E2=94=82 =E2=95=B0=E2=94=80 'j' = =E2=94=82 UNINIT(int) > =E2=94=82 =E2=94=82 =E2=95=B0=E2=94=80 frame@1 'bar' =E2= =94=82 > =E2=94=82 =E2=94=82 =E2=95=B0=E2=94=80 'k' =E2= =94=82 > =E2=94=82 =E2=94=82 =E2=95=B0=E2=94=80 [3] =E2= =94=82 > =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80 .x INIT_VAL(p) =E2= =94=82 > =E2=94=82 =E2=94=82 =E2=95=B0=E2=94=80 .y INIT_VAL(q) =E2= =94=82 > =E2=94=82 =E2=95=B0=E2=94=80 Globals =E2=94=82 > =E2=94=82 =E2=95=B0=E2=94=80 'baz' =E2=94=82 > =E2=94=9C=E2=94=80 Constraints > =E2=94=82 =E2=95=B0=E2=94=80 (etc) > =E2=95=B0=E2=94=80 'malloc' state > =E2=95=B0=E2=94=80 CONJURED_VALUE('ptr') unchecked('free') > > > That said, our "tree" structure is arguably a directed graph rather > than a tree (consider e.g. types) > > > > > Incidentially this looks like something fit for a google summer of > > code project. > > Ideally it would hook into print-tree.cc providing an alternate > > structured output. > > It currently prints in the style > > > > > type > type > unsigned HI > > size > > unit-size > > align:16 warn_if_not_align:0 symtab:0 alias-set -1 > > canonical-type 0x7ffff702b540 precision:16 min > 0x7ffff702d138 0> max > > > QI > > size > > unit-size > > ... > > > > where you can see it follows tree -> tree edges up to some depth > > (and avoids repeated expansion). When debugging that's all I have > > and I have to follow edges by matching up the raw addresses printed, > > re-dumping those that didn't get expanded. HTML would be indeed > > so much nicer here (and a more complete output). > > > > From a maintainance point I think it's important to have "dump a tree > > node" > > once, so when fields are added or deemed useful for presenting in a > > dump > > you don't have to chase down more than one place. Maintenance is > > also > > the reason to not simply accept your contribution as-is. > > Presumably we'd want some kind of "visitor" code that captures visiting > the fields of each type in one place, allowing for different consumers > of this data (HTML generation, JSON generation etc). Though I'm not > sure how best to express this double-dispatch (by templates, vfunc, or > whatnot). > > We already have some of this in the form of gengtype and what it > generates, but I suspect we don't want to add further reliance on > gengtype. > > > > > I do hope this eventually gets picked up. I've added a project idea > > to https://gcc.gnu.org/wiki/SummerOfCode > > and would be willing to mentor it. > > FWIW you added it to the "Other projects and project ideas" below > "Other Project Ideas", where it's much less likely to get noticed than > under the "Selected Project Ideas". Yeah, I didn't feel it was "Selected", but maybe that doesn't mean anything? > > > > Oh, and I'm looking forward to the actual Cobol work! > > Likewise > > [...snip...] > > Dave >