From: "Martin Liška" <mliska@suse.cz>
To: Richard Biener <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [RFC][PATCH] Introduce -fdump*-folding
Date: Tue, 09 May 2017 12:52:00 -0000 [thread overview]
Message-ID: <267cb74c-efb3-06e0-c207-e4f5a83e313d@suse.cz> (raw)
In-Reply-To: <CAFiYyc3MFNV2OqKLPF7w-mW_GKLU8c+1phuCLurBQAiZ-n2Raw@mail.gmail.com>
On 05/09/2017 02:16 PM, Richard Biener wrote:
> On Tue, May 9, 2017 at 2:01 PM, Martin Liška <mliska@suse.cz> wrote:
>> 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
>> - ...
>>
>> ?
>
> Yeah. As said the motivation was to escape the 32 (now 64) bits limitation,
> not to make the user interface into a hierarchy.
>
> I suppose we can easily defer now given we have 32 bits available now ;)
I see. Hopefully we can live quite some time with another 32 bits and I'm going
to transform the TDF_* stuff to enum.
Martin
>
> Richard.
>
>>>
>>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
next prev parent reply other threads:[~2017-05-09 12:46 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-03 8:14 Martin Liška
2017-05-03 8:20 ` Andrew Pinski
2017-05-03 10:16 ` Richard Biener
2017-05-04 9:23 ` Martin Liška
2017-05-04 10:41 ` Richard Biener
2017-05-04 12:06 ` Martin Liška
2017-05-05 10:44 ` [PATCH 1/N] Introduce dump_flags_t type and use it instead of int type Martin Liška
2017-05-05 11:50 ` Richard Biener
2017-05-06 15:04 ` Trevor Saunders
2017-05-12 13:01 ` [PATCH v2 01/N] Add default value for last argument of dump functions Martin Liška
2017-05-16 13:49 ` Richard Biener
2017-05-12 13:04 ` [PATCH v2 2/N] Introduce dump_flags_t type and use it instead of int, type Martin Liška
2017-05-16 13:50 ` Richard Biener
2017-05-16 14:56 ` Martin Liška
2017-05-17 7:55 ` Richard Biener
2017-05-17 9:06 ` Martin Liška
2017-05-18 13:37 ` Thomas Schwinge
2017-05-18 14:26 ` Martin Liška
2017-05-12 13:30 ` [PATCH v2 3/N] Transform TDF_{lang,tree,ipa,rtl} to dump_kind enum Martin Liška
2017-05-16 14:17 ` Richard Biener
2017-05-17 12:22 ` Richard Biener
2017-05-18 12:37 ` Martin Liška
2017-05-25 5:29 ` Martin Sebor
2017-05-25 9:56 ` Martin Liška
2017-05-25 10:58 ` Nathan Sidwell
2017-05-26 13:00 ` Richard Biener
2017-05-26 13:54 ` Martin Liška
2017-05-30 11:46 ` Richard Biener
2017-05-16 13:55 ` [PATCH v2 04/N] Simplify usage of some TDF_* flags Martin Liška
2017-05-17 12:37 ` Richard Biener
2017-05-18 12:58 ` Martin Liška
2017-05-24 21:23 ` Martin Liška
2017-05-26 11:46 ` Richard Biener
2017-05-24 11:04 ` [PATCH v2 05/N] Add -fdump*-folding suboption Martin Liška
2017-05-24 13:53 ` Richard Biener
2017-05-05 10:56 ` [PATCH 2/N] Add dump_flags_type<E> for handling of suboptions Martin Liška
2017-05-09 12:05 ` Martin Liška
2017-05-12 17:47 ` Martin Sebor
2017-05-15 6:52 ` Martin Sebor
2017-05-15 9:47 ` [RFC] Do we want hierarchical options & encapsulation in a class Martin Liška
2017-05-15 11:26 ` Nathan Sidwell
2017-05-15 12:24 ` Martin Liška
2017-05-15 11:46 ` Nathan Sidwell
2017-05-15 12:05 ` Martin Liška
2017-05-15 12:43 ` Nathan Sidwell
2017-05-15 13:50 ` Martin Liška
2017-05-15 14:13 ` Nathan Sidwell
2017-05-15 14:24 ` Martin Liška
2017-05-16 13:44 ` Richard Biener
2017-05-05 11:57 ` [RFC][PATCH] Introduce -fdump*-folding Richard Biener
2017-05-09 12:03 ` Martin Liška
2017-05-09 12:19 ` Richard Biener
2017-05-09 12:52 ` Martin Liška [this message]
2017-05-09 13:01 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=267cb74c-efb3-06e0-c207-e4f5a83e313d@suse.cz \
--to=mliska@suse.cz \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).