On Thu, May 4, 2017 at 1:10 PM, Martin Liška <mli...@suse.cz> wrote: > On 05/04/2017 12:40 PM, Richard Biener wrote: >> >> On Thu, May 4, 2017 at 11:22 AM, Martin Liška <mli...@suse.cz> wrote: >>> >>> On 05/03/2017 12:12 PM, Richard Biener wrote: >>>> >>>> >>>> On Wed, May 3, 2017 at 10:10 AM, Martin Liška <mli...@suse.cz> wrote: >>>>> >>>>> >>>>> Hello >>>>> >>>>> Last release cycle I spent quite some time with reading of IVOPTS pass >>>>> dump file. Using -fdump*-details causes to generate a lot of 'Applying >>>>> pattern' >>>>> lines, which can make reading of a dump file more complicated. >>>>> >>>>> There are stats for tramp3d with -O2 and -fdump-tree-all-details. >>>>> Percentage number >>>>> shows how many lines are of the aforementioned pattern: >>>>> >>>>> tramp3d-v4.cpp.164t.ivopts: 6.34% >>>>> tramp3d-v4.cpp.091t.ccp2: 5.04% >>>>> tramp3d-v4.cpp.093t.cunrolli: 4.41% >>>>> tramp3d-v4.cpp.129t.laddress: 3.70% >>>>> tramp3d-v4.cpp.032t.ccp1: 2.31% >>>>> tramp3d-v4.cpp.038t.evrp: 1.90% >>>>> tramp3d-v4.cpp.033t.forwprop1: 1.74% >>>>> tramp3d-v4.cpp.103t.vrp1: 1.52% >>>>> tramp3d-v4.cpp.124t.forwprop3: 1.31% >>>>> tramp3d-v4.cpp.181t.vrp2: 1.30% >>>>> tramp3d-v4.cpp.161t.cunroll: 1.22% >>>>> tramp3d-v4.cpp.027t.fixup_cfg3: 1.11% >>>>> tramp3d-v4.cpp.153t.ivcanon: 1.07% >>>>> tramp3d-v4.cpp.126t.ccp3: 0.96% >>>>> tramp3d-v4.cpp.143t.sccp: 0.91% >>>>> tramp3d-v4.cpp.185t.forwprop4: 0.82% >>>>> tramp3d-v4.cpp.011t.cfg: 0.74% >>>>> tramp3d-v4.cpp.096t.forwprop2: 0.50% >>>>> tramp3d-v4.cpp.019t.fixup_cfg1: 0.37% >>>>> tramp3d-v4.cpp.120t.phicprop1: 0.33% >>>>> tramp3d-v4.cpp.133t.pre: 0.32% >>>>> tramp3d-v4.cpp.182t.phicprop2: 0.27% >>>>> tramp3d-v4.cpp.170t.veclower21: 0.25% >>>>> tramp3d-v4.cpp.029t.einline: 0.24% >>>>> >>>>> I'm suggesting to add new TDF that will be allocated for that. >>>>> Patch can bootstrap on ppc64le-redhat-linux and survives regression >>>>> tests. >>>>> >>>>> Thoughts? >>>> >>>> >>>> >>>> Ok. Soon we'll want to change dump_flags to uint64_t ... (we have 1 >>>> bit >>>> left >>>> if you allow negative dump_flags). It'll tickle down on a lot of >>>> interfaces >>>> so introducing dump_flags_t at the same time might be a good idea. >>> >>> >>> >>> Hello. >>> >>> I've prepared patch that migrates all interfaces and introduces >>> dump_flags_t. >> >> >> Great. >> >>> I've been >>> currently testing that. Apart from that Richi requested to come up with >>> more >>> generic approach >>> of hierarchical structure of options. >> >> >> Didn't really "request" it, it's just something we eventually need to do >> when >> we run out of bits again ;) > > > I know, but it was me who came up with the idea of more fine suboptions :) > >> >>> >>> Can you please take a look at self-contained source file that shows way >>> I've >>> decided to go? >>> Another question is whether we want to implement also "aliases", where >>> for >>> instance >>> current 'all' is equal to union of couple of suboptions? >> >> >> Yeah, I think we do want -all-all-all and -foo-all to work. Not sure >> about -all-foo-all. > > > Actually only having 'all' is quite easy to implement. > > Let's imagine following hierarchy: > > (root) > - vops > - folding > - gimple > - ctor > - array_ref > - arithmetic > - generic > - c > - c++ > - ctor > - xyz > > Then '-fdump-passname-folding-all' will be equal to > '-fdump-passname-folding'.
Ok, so you envision that sub-options restrict stuff. I thought of -gimple -vops -generic -folding so the other way around. We do not have many options that would be RTL specific but gimple only are -vops -alias -scev -gimple -rhs-only -verbose -memsyms while RTL has -cselib. -eh sounds gimple specific. Then there's the optgroup stuff you already saw. So it looks like a 8 bit "group id" plus 56 bits of flags would do. Yes, this implies reworking how & and | work. For example you can't | dump-flags of different groups. >> >> The important thing is to make sure dump_flags_t stays POD and thus is >> eligible to be passed in register(s). In the end we might simply come up >> with a two-level hierarchy, each 32bits (or we can even get back to 32bits >> in total with two times 16bits). > > > I'm aware of having the type as POD. > >> >> It looks you didn't actually implement this as a hierarchy though but >> still allocate from one pool of bits (so you only do a change to how >> users access this?) > > > Yep, all leaf options are mapped to a mask and all inner nodes are just > union > of suboptions. That will allow us to have 64 leaf suboptions. Reaching the > limit > we can encode the values in more sophisticated way. That however brings need > to implement more complicated '&' and '|' operators. > > I'll finish the implementation and try to migrate that to current handling. > Guess, I'm quite close. Hmm, but then there's not much advantage in suboptions (well, apart from maybe at the user-side). > Martin > > >> >> Thanks, >> Richard. >> >>> >>> Thanks for feedback, >>> Martin >>> >>>> >>>> Thanks, >>>> Richard. >>>> >>>>> Martin >>> >>> >>> >
