On 10/30/25 3:12 PM, Marek Polacek wrote:
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.
I agree that it's OK to be slower; it also seems fine to add 2k of
rodata. I don't have much of a preference, either is OK.
Jason
