From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14296 invoked by alias); 20 Oct 2011 08:52:06 -0000 Received: (qmail 14280 invoked by uid 22791); 20 Oct 2011 08:52:05 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yx0-f175.google.com (HELO mail-yx0-f175.google.com) (209.85.213.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Oct 2011 08:51:48 +0000 Received: by yxj20 with SMTP id 20so309694yxj.20 for ; Thu, 20 Oct 2011 01:51:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.13.6 with SMTP id d6mr950447obc.11.1319100707521; Thu, 20 Oct 2011 01:51:47 -0700 (PDT) Received: by 10.182.28.138 with HTTP; Thu, 20 Oct 2011 01:51:47 -0700 (PDT) In-Reply-To: <20111020083652.GA12230@ours.starynkevitch.net> References: <20111019232801.3532EC1F62@rong.mtv.corp.google.com> <20111020083652.GA12230@ours.starynkevitch.net> Date: Thu, 20 Oct 2011 12:05:00 -0000 Message-ID: Subject: Re: new patches using -fopt-info (issue5294043) From: Richard Guenther To: Basile Starynkevitch Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2011-10/txt/msg00341.txt.bz2 On Thu, Oct 20, 2011 at 10:36 AM, Basile Starynkevitch wrote: > On Thu, Oct 20, 2011 at 10:21:27AM +0200, Richard Guenther wrote: > >> I'd rather have a way to make dump-files more structured (so, following >> some standard reporting scheme) than introducing yet another way >> of output. =A0[after making dump-files more consistent it will be easy >> to revisit patches like this, there would be a natural general central >> way to implement it] > > I'm not sure to understand what more structured dump-files mean. Are you > thinking of making them in XML or in JSON format (both requires some mini= mal > structure). No, with structured I mean passes should dump things in a common format. Which in the end is achieved most easily by providing some helpers that take care of the formatting details. Consider the various ways passes dump that they simplified a statement. Or the various ways passes dump a kind of lattice they computed for all SSA names, or how they dump informati= on on some loop. > >> So, please fix dump-files instead. > > I'm not sure to understand what that means, because I am not sure to grasp > the intended meaning and roles of dump files (in particular, from a plugin > point of view). And I'm not sure to understand what fixing them means. I don't see how plugins come into the picture here or how they should be any different from the core compiler. > > My incomplete understanding is that dump files are for any kind of > GCC-debugging (or GCC-plugin-debuggging) output which any pass might feel > useful, but that is probably too weak as a definition. Or are dump files > something more precise that that? No, that's exactly what they are about. They are already structured by means of the dump-file modifiers (the TDF_ flags), so you can already filter the output. It should be simple to extend this, and at the end, select a part of the output to stdout as well. Richard.