From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 335 invoked by alias); 15 May 2017 12:04:06 -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 130061 invoked by uid 89); 15 May 2017 12:04:05 -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,SPF_PASS autolearn=ham version=3.3.2 spammy=explains X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 15 May 2017 12:04:03 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id DAB10AB9F; Mon, 15 May 2017 12:04:03 +0000 (UTC) Subject: Re: [RFC] Do we want hierarchical options & encapsulation in a class To: Nathan Sidwell , Richard Biener Cc: GCC Patches , Martin Sebor References: <668c62b5-9603-47c5-9bfe-266d0d369a1f@suse.cz> <412435ae-4a9b-99ff-cb78-cf157b778303@suse.cz> <8cca10ba-1a98-2e0d-2fbd-ce1c1c4df1c2@suse.cz> <2ab5f23c-b221-eca9-9dd7-2fba69cfc2cc@suse.cz> <63638573-4c8d-8bea-f575-2c9025588a49@acm.org> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <0baf7bdc-919f-851e-8ed3-4e970d60c921@suse.cz> Date: Mon, 15 May 2017 12:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <63638573-4c8d-8bea-f575-2c9025588a49@acm.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg01172.txt.bz2 On 05/15/2017 01:33 PM, Nathan Sidwell wrote: > Martin, > thanks for the write up. > > On 05/15/2017 05:39 AM, Martin Liška wrote: >> Thanks Martin for feedback! After I spent quite some time with fiddling with > the options, I'm not convinced we should convert options to more > hierarchical> structure. There's description: >> 1) -fopt-info is used to dump optimization options. One can pick both verbosity >> (note, optimization, all) and an optimization (ipa, inline, vec,...). Thus said >> it's probably not a candidate for hierarchical options? > > I've never used this option, so have no comment (too lazy to figure out if it told me anything I didn't already see in a dump I was groveling over). Hi. Thanks for feedback, I'll mention -fopt-info later in this email. > >> 2) -fdump-pass_name-... as mentioned by Nathan is combination of verbosity >> (graph, note, verbose, details) and specific type of options (VOPS, RHS_ONLY, UID,..). >> >> There's a complete list and suggestion how we can move it to more hierarchical ordering: >> >> #define TDF_ADDRESS >> #define TDF_SLIM >> #define TDF_RAW >> #define TDF_DETAILS >> #define TDF_STATS >> #define TDF_BLOCKS >> #define TDF_VOPS >> #define TDF_LINENO >> #define TDF_UID > #define TDF_LANG is now a thing too. it should be DI_kind too >> #define TDF_TREE - remove & replace with DI_kind >> #define TDF_RTL - remove & replace with DI_kind >> #define TDF_IPA - remove & replace with DI_kind >> #define TDF_STMTADDR - merge with TDF_ADDRESS >> #define TDF_GRAPH >> #define TDF_MEMSYMS >> #define TDF_DIAGNOSTIC - merge with TDF_DETAILS >> #define TDF_VERBOSE - merge with TDF_DETAILS >> #define TDF_RHS_ONLY >> #define TDF_ASMNAME >> #define TDF_EH >> #define TDF_NOUID >> #define TDF_ALIAS >> #define TDF_ENUMERATE_LOCALS >> #define TDF_CSELIB >> #define TDF_SCEV >> #define TDF_COMMENT - remove and dump ';; ' unconditionally >> #define TDF_GIMPLE > > Looks a good start. > > 1) The TDF_UID and TDF_NOUID options seem to be inverses of each other. Can't we just ditch the latter? One is used to paper over UIDs in order to preserve -fdebug-compare (I believe). And the second one is used to dump UIDd basically for *_DECL. As any of these is not default, both make sense. > > 2) We might want to distinguish between enabling dump information that is useful to us gcc developers (TDF_DETAILS, say), and that that would be useful to end users trying to figure out why some random loop isn't being optimized in (say TDF_DIAGNOSTIC). But if we can't define a sensible way of distinguishing then I'm all for not making the distinction. That's probably motivation behind -fopt-info, which should represent "Optimization dumps", readable by user. To be honest, just a part of optimizations can be found in these files (vectorization and loop optimization). The rest lives in normal -fdump-xyz*. Maybe this can be opportunity to clean it up? > >> and more hierarchical ordering can be: >> >> #define TDF_ADDRESS >> #define TDF_SLIM >> #define TDF_RAW >> #define TDF_DETAILS >> #define TDF_STATS >> #define TDF_BLOCKS >> #define TDF_LINENO >> #define TDF_UID >> #define TDF_GRAPH >> #define TDF_ASMNAME >> #define TDF_NOUID >> #define TDF_ENUMERATE_LOCALS > > It'd be nice to name TDF_ENUMERATE_LOCALS without the second _ to avoid confusion with the hierarchy you discuss below? (perhaps TDF_LOCALS?) Yep, works for me. > > I like the idea of naming flags specific to a particular kind of dump with the name of that kind of dump. We do have a mismatch between DI_TREE and TDF_GIMPLE though -- is there something sensible we could do there? > >> #define TDF_GIMPLE >> #define TDF_GIMPLE_FE - GIMPLE front-end As we have couple of dump flags used just for GIMPLE dumps, my idea was to give them common predecessor (TDF_GIMPLE). Which explains why current TDF_GIMPLE (GIMPLE FE) needs to be renamed. > > How might this differ from a new -fdump-lang-original? I.e. > (1) why is it a dump-modifier flag, rather than a dump in its own right Because you can use it for all gimple/tree passes to produce input for GIMPLE FE. > (2) if we do need it, name it TDF_GIMPLE_LANG Can be done that. > >> #define TDF_GIMPLE_VOPS >> #define TDF_GIMPLE_EH >> #define TDF_GIMPLE_ALIAS >> #define TDF_GIMPLE_SCEV >> #define TDF_GIMPLE_MEMSYMS >> #define TDF_GIMPLE_RHS_ONLY >> >> #define TDF_RTL > > How does this differ from the current TDF_RTL meaning? Is it implying 'TDF_RTL_ALL'? (same question about TDF_GIMPLE). Yes, -fdump-tree-xyz-rtl would be equal to -fdump-tree-xyz-rtl-all. Martin > >> #define TDF_RTL_CSELIB > > nathan