https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101163
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-06-22
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords| |compile-time-hog
CC| |nathan at gcc dot gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed on trunk. There are linked-lists involved, so not unexpected I
guess.
The top functions in a profile of an unoptimized cc1plus are
fields_linear_search
and member_vec_linear_search called from get_class_binding[_direct] called
ultimatively from lookup_member.
Nathan did a lot of name-lookup refactoring for modules but the core data
structures stayed the same I guess.
In the linear list walk a quite big chunk of the constant overhead is the
anon aggregate check:
static tree
fields_linear_search (tree klass, tree name, bool want_type)
{
for (tree fields = TYPE_FIELDS (klass); fields; fields = DECL_CHAIN (fields))
{
tree decl = fields;
if (TREE_CODE (decl) == FIELD_DECL
&& ANON_AGGR_TYPE_P (TREE_TYPE (decl)))
{
if (tree temp = search_anon_aggr (TREE_TYPE (decl), name, want_type))
return temp;
}
if (DECL_NAME (decl) != name)
continue;
if there was a bit on the FIELD_DECL instead of the extra indirection that
would help this a lot (by a constant factor).
Of course a linear search should be a no-go ...
