This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: tree-ipa-type-escape slow


the splay tree in question is there as part of the type unification.

This is required because our design for combining modules does not unify the types and this messes up the type escape analysis.

Because of this, the type name must be the key. However, there is the possibility that doing some special treatment for unnamed types is possible. I did not look into it. I do not understand the front ends enough to know how often these are created.

Is this a c++ issue? or an issue associated with only this benchmark?

kenny



Richard Guenther wrote:
I'm seeing splay tree usage from tree-ipa-type-escape in the first
places of profiles from tramp3d-v4:

samples % image name app name symbol name
141814 6.5462 no-vmlinux no-vmlinux (no symbols)
71471 3.2992 cc1plus cc1plus splay_tree_splay_helper
51114 2.3595 cc1plus cc1plus comptypes
49001 2.2619 cc1plus cc1plus compute_may_aliases



-------------------------------------------------------------------------------
11160 15.6147 cc1plus cc1plus splay_tree_splay
59855 83.7473 cc1plus cc1plus splay_tree_splay_helper
71471 3.2992 cc1plus cc1plus splay_tree_splay_helper
71471 43.1489 cc1plus cc1plus splay_tree_splay_helper [self]
59855 36.1360 cc1plus cc1plus splay_tree_splay_helper
12966 7.8279 libc-2.3.5.so cc1plus strcmp
11404 6.8849 cc1plus cc1plus compare_type_brand
8650 5.2222 cc1plus cc1plus splay_tree_compare_pointers
-------------------------------------------------------------------------------


looking into the ipa-type-escape code I wonder if there's a reason
to use TYPE_NAME as a key instead of TYPE_UID.  Also if TYPE_NAME
is necessary, instead of using "<unnamed>" using NULL and special
casing that will be a lot faster, too.  Can you elaborate on what
exactly the datastructure is used for?  Maybe for a large number
of types it isn't really the most efficient one.

Thanks,
Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]