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
