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

2017-05-16 Thread Richard Biener
On Mon, May 15, 2017 at 4:21 PM, Martin Liška 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 o

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

2017-05-15 Thread Martin Liška
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

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

2017-05-15 Thread Nathan Sidwell
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 en

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

2017-05-15 Thread Martin Liška
On 05/15/2017 02:24 PM, Nathan Sidwell wrote: > On 05/15/2017 08:04 AM, Martin Liška wrote: >> On 05/15/2017 01:33 PM, Nathan Sidwell wrote: > >>> 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 or

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

2017-05-15 Thread Nathan Sidwell
On 05/15/2017 08:04 AM, Martin Liška wrote: On 05/15/2017 01:33 PM, Nathan Sidwell wrote: 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

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

2017-05-15 Thread Martin Liška
On 05/15/2017 01:18 PM, Nathan Sidwell wrote: > 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 > > I'll respond to Martin's email properly s

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

2017-05-15 Thread Martin Liška
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>

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

2017-05-15 Thread Nathan Sidwell
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 du

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

2017-05-15 Thread Nathan Sidwell
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 I'll respond to Martin's email properly separates, but while we're on dump redesign, here's a W

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

2017-05-15 Thread Martin Liška
Hello. 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, al