On 05/05/2017 01:50 PM, Richard Biener wrote: > 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.
Well, I'm not opposed to idea of converting that to way you described. So, you're willing to introduce something like: (root) - generic - eh - folding - ... - gimple - vops - folding - rhs-only - ... - vops - rtl - cselib - ... ? > >>> >>> 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). Yep, please take a look at updated version of PATCH 2/N, where I ported -fopt-info. As you can see I had to explicitly define all enum values and hierarchy creation of every single node. Martin > >> Martin >> >> >>> >>> Thanks, >>> Richard. >>> >>>> >>>> Thanks for feedback, >>>> Martin >>>> >>>>> >>>>> Thanks, >>>>> Richard. >>>>> >>>>>> Martin >>>> >>>> >>>> >>