[RFC][PATCH] Introduce -fdump*-folding
Martin Liška
mliska@suse.cz
Tue May 9 12:03:00 GMT 2017
On 05/05/2017 01:50 PM, Richard Biener wrote:
> 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.
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
>>>>
>>>>
>>>>
>>
More information about the Gcc-patches
mailing list