From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 5D94F3858C52 for ; Wed, 28 Feb 2024 08:25:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5D94F3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5D94F3858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709108739; cv=none; b=rcUFOKkxkHhbpZPOZpJSioFolvjbB8katXgY7cPGLds2F83ZpfFHrAe8m7WLFg8zX3T5hZ6y23UsxTOssFFyBzuxX4Ziun41R2AtiScuom+4Akujw8TizIUs8TlVzFCuOL5OHrcnopoVFUXqW0MfBz9aFvAflVpXVT6Y0nkZbpM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709108739; c=relaxed/simple; bh=gzliDPQVUq1636ftzOaZdBnfea+XQQOMQ9DlfMNCSOY=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=UvGGHReYU/fLwnyqSauPrs85e1IhpKgJqN4LBgZOB+Xi0CzJP1MCzkXayWBXekIxNYZhGHk6RFHZHckpPo2+axPm8eUB1Nz8vGFsLYq/fECZ9WIvsD/qHgOFrMBAfupfBHUf39jhh5qYDlvOUnuOkKBhliIp1DhUZqe4Ms51uGQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709108735; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=ipYHbFPHMrDEhmew+G5JgZA6SR/c3WSeQ3xWLW7BLts=; b=DgHrghMktfYp4uPvpx8kbRVlzPmNsvKgxRv9czLrZPV5YGAFLbkmCiHbDkkCgjOv0P0W1m 9F9pwpWGf8IP+PZRshwsUFR6wsnfGepVnfLUgXWK/T9qvndtahXKKLLIIdnXd2mcc2DuLC aL187Exz4qnNwOSn2saucfXnqqhfkI4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-613-BmT3oytwMJq5YZxjEh9OPQ-1; Wed, 28 Feb 2024 03:25:31 -0500 X-MC-Unique: BmT3oytwMJq5YZxjEh9OPQ-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A0949185A782; Wed, 28 Feb 2024 08:25:31 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 61F9A200A382; Wed, 28 Feb 2024 08:25:31 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 41S8PSEr2997364 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 28 Feb 2024 09:25:29 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 41S8PRek2997363; Wed, 28 Feb 2024 09:25:27 +0100 Date: Wed, 28 Feb 2024 09:25:27 +0100 From: Jakub Jelinek To: Richard Biener Cc: Robert Dubner , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] developer option: -fdump-generic-nodes; initial incorporation Message-ID: Reply-To: Jakub Jelinek References: <009401da65ae$8790a750$96b1f5f0$@symas.com> <09de01da69c2$c5f57260$51e05720$@symas.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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 08:58:08AM +0100, Richard Biener wrote: > 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 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). I think keeping the current format of what is printed but optionally just turn all those addresses in there into hyperlinks which would expand the other trees would be nice. Maybe also allow just hovering on the link and show the other tree printed might be nice too. Folding it all into just ...> would mean one can't quickly access just the min/max or fn return type etc. We might need some parameter how deep to go (and/or how many trees to dump at most) so that we don't dump into HTML gigabytes of data when asking to print say a large BIND_EXPR into HTML. Jakub