Re: [RFC] Do we want hierarchical options & encapsulation in a class

[Nathan Sidwell <nathan@acm.org>]

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).

> 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?

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.

> 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?)

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

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
(2) if we do need it, name it TDF_GIMPLE_LANG

> #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).

> #define TDF_RTL_CSELIB

nathan
-- 
Nathan Sidwell