On Mon, May 15, 2017 at 4:21 PM, Martin Liška <mli...@suse.cz> wrote: > On 05/15/2017 04:12 PM, Nathan Sidwell wrote: >> On 05/15/2017 09:06 AM, Martin Liška wrote: >> >>>> Given a blank sheet of paper, the current 'TDF_tree' dumps should really >>>> be 'TDF_gimple' dumps, so we'd have lang/ipa/gimple/rtl kinds of dumps. >>>> Such a renaming may be an unacceptable amount of churn though. >>> >>> Well, I would prefer to introduce new enum for kind of dump: >>> https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01033.html >> >> Right, I understand that. My point is that it might be confusing to users >> of the dump machinery (i.e. me), at the command-line level where 'rtl' means >> different things in different contexts. And we have 'tree' dumps that dump >> gimple and 'lang' dumps that also (can) dump trees. > > Right. To be honest, originally I was convinced about positive impact of > hierarchical options. But changing names of dump suboptions will bring > inconvenience for current developers of GCC (who mainly use it). And I also > noticed that one can write -fdump-tree-ifcvt-stats-blocks-details, > a combination of multiple suboptions. Which makes it even more complex :) > > That said, I'm not inclining to that. Then it's questionable whether to > encapsulate masking enum to a class?
So replying to the last mail in this thread. Originally the motivation was to get more bits when we disallow some flags for some categories (lang, tree, rtl, ipa). Now given that we have 32bits free and that Nathans TDF_lang stuff should add missing hierarchy the only user-visible change I'd do is to disallow for example -fdump-rtl-vops or -fdump-tree-note with a diagnostic. That allows us to allocate overlapping bits. Like if we move TDF_* to a .def file and have DEFFLAG(EH, GIMPLE|RTL) DEFFLAG(NOTE, INFO) DEFFLAG(SCEV, GIMPLE) etc. and some "intelligent" generator that allocates the bits. Now, given we have 32bit free the pressure to do this is quite low (and I usally dislike changes that are just there for the sake of changes). Given the introduction of -lang, which I appreciate, there's the opportunity to do better than currently, esp. with respect to maintainance of dump flags and the machinery. I realize this doesn't really answer whether we want a class or a enum or a uint64_t for dump_flags. A class would be most forward-looking. An enum for the bit number then works well (I dislike "sparse" enums), so operator|, etc. would do the missing 1<< Richard. > Martin > >> >> We have a bunch of gimple optimization passes, but call the dumpers 'tree'. >> I know how we ended up here, but it seems confusing. >> >> nathan >> >
