From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76171 invoked by alias); 10 May 2017 17:58:33 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 76161 invoked by uid 89); 10 May 2017 17:58:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 May 2017 17:58:31 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 118148124D; Wed, 10 May 2017 17:58:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 118148124D Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 118148124D Received: from tucnak.zalov.cz (ovpn-116-29.ams2.redhat.com [10.36.116.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ADA828AC5D; Wed, 10 May 2017 17:58:32 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v4AHwUIi017768; Wed, 10 May 2017 19:58:30 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v4AHwR9d017767; Wed, 10 May 2017 19:58:27 +0200 Date: Wed, 10 May 2017 17:59:00 -0000 From: Jakub Jelinek To: Alexander Monakov Cc: Richard Biener , Nathan Sidwell , GCC Patches Subject: Re: [PATCH] Kill -fdump-translation-unit Message-ID: <20170510175826.GH1809@tucnak> Reply-To: Jakub Jelinek References: <964bab70-9a78-6812-4697-7c0c0f2dc096@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00814.txt.bz2 On Wed, May 10, 2017 at 08:51:22PM +0300, Alexander Monakov wrote: > On Wed, 10 May 2017, Richard Biener wrote: > > > On Tue, May 9, 2017 at 5:41 PM, Nathan Sidwell wrote: > > > -fdump-translation-unit is an inscrutably opaque dump. It turned out that > > > most of the uses of the tree-dump header file was to indirectly get at > > > dumpfile.h, and the dump_function entry point it had forwarded to a dumper > > > in tree-cfg.c. The gimple dumper would use its node dumper when asked for a > > > raw dump, but that was about it. > > > > > > We have prettier printers now. This patch nukes the tu dumper. ok? > > > > Ok if nobody objects within 24 hours. > > There was a reasonable IMO objection on the IRC (sadly, I can't say the same > about the responses that person received from Nathan). > > A quick search indicates that people have published .tu parsers in Perl, JS > (producing json), the person objecting on IRC apparently used Python, and I'm > aware of another Python-based parser by Bruce Merry. > > My takeaway from this is that people cared enough about this to build and > publish parsers in their language of choice, and that apparently it is or was > feature-rich enough for them to use. Despite the format being undocumented and > formally not supported. > > The motivation put forward in the opening mail ("is an inscutably opaque dump") > seems like a weak reason for removal. Can it at least be taken out of -fdump-tree-all? It is huge, often larger than the sum of all the other dump files, and don't remember ever using it for anything. Instead of trying to write a parser for it and reconstructing something you can then later analyze, isn't it better to just write a plugin that can analyze it directly? Jakub