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'.
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.
Martin
Thanks,
Richard.
Thanks for feedback,
Martin
Thanks,
Richard.
Martin
