On Thu, Oct 30, 2025 at 09:20:33AM +0100, Jakub Jelinek wrote:
> Hi!
>
> When converting reflection metafunction evaluation into gperf, I had
> a look at the other *.gperf files in gcc/cp/.
> cfns.gperf doesn't have any hash conflicts, but std-name-hint.gperf
> has 7, which I believe means that for 7 of the strings it falls back to some
> slow loop over not sure how many entries.
>
> Apparently, 2 out of the 7 conflicts are just because two lines are
> identically duplicated in the file, the patch included below fixes that.
> Bootstrapped/regtested on x86_64-linux and i686-linux successfully.
>
> The attached patch is a variant to that, which replaces -k '1,2,7,11,$'
> with -k '1,2,4,6,7,11,14,$' which is the minimum option that results
> in no conflicts. Compared to the included patch, this results on x86_64
> in small shrinks in .text/.eh_frame and larger growth in .rodata section:
> .text -256 bytes
> .rodata +2368 bytes
> .eh_frame -80 bytes
> Plus guess the hash function will now be slightly more costly as it needs
> to hash in 7 characters instead of 4, but doesn't need the
> - else if (index < -TOTAL_KEYWORDS)
> - {
> - int offset = - 1 - TOTAL_KEYWORDS - index;
> - const struct std_name_hint *wordptr = &wordlist[TOTAL_KEYWORDS
> + lookup[offset]];
> - const struct std_name_hint *wordendptr = wordptr +
> -lookup[offset + 1];
> -
> - while (wordptr < wordendptr)
> - {
> - const char *s = wordptr->name;
> -
> - if (*str == *s && !strcmp (str + 1, s + 1))
> - return wordptr;
> - wordptr++;
> - }
> - }
> fallback.
>
> Maybe the growth of +2368 .rodata bytes is too much and we can live with
> 5 out of the 486 names being slightly slower (though, unsure what it also
> means for unsuccessful lookups). If so, ok to commit the first (included
> patch)?
FWIW, since get_std_name_hint is used for error paths -- missing headers
and similar -- I think it's OK to be slower and do a bunch of strcmps.
So personally I'd go with the first patch only. Others may disagree.
Marek
