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.
