Re: [RFC][PATCH] Introduce -fdump*-folding

[Richard Biener <richard dot guenther at gmail dot com>]

On Thu, May 4, 2017 at 1:10 PM, Martin Liška <mliska@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 <mliska@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 <mliska@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
>>>
>>>
>>>
>