This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?

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
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]