Re: PATCH: use hashtab for pseudo op table

[Zack Weinberg <zack at codesourcery dot com>]

Nick Clifton <nickc@redhat.com> writes:
>
> I guess the question comes down to - should bfd keep or re-implement
> its own hashtab code to be used everywhere in binutils or should the
> one from libiberty be used ?  Zack pointed out the performance penalty
> of using libiberty's code, and I would like to get a feel for whether
> this would be a serious hindrance to using it.

The auto-resizing certainly would be nice to have.  I'm not just
bringing up the indirect function call penalty as a hypothetical,
though; over in GCC we got measurable speedups by switching back to a
custom hash table (libcpp/symtab.c) for identifier lookups.  I don't
know whether the assembler's parse pass bottlenecks in the same places
that GCC's parsers do, but it wouldn't surprise me -- parsers is
parsers.

I'm also concerned with hashtab.c's interface being significantly
messier.  Take this example from (my revision of) the ARM assembler
(with some irrelevant material left out):

  const struct asm_opcode *opcode;

  for (base = end = *str; *end != '\0'; end++)
    if (*end == ' ' || (unified_syntax && *end == '.'))
      break;

  opcode = hash_find_n (arm_ops_hsh, base, end - base);

If arm_ops_hsh were a libiberty hash table, I would instead have to
write

  const struct asm_opcode *opcode;
  struct asm_opcode key;
  char *namep;

  for (base = end = *str; *end != '\0'; end++)
    if (*end == ' ' || (unified_syntax && *end == '.'))
      break;

  namep = alloca (end - base + 1);
  memcpy (namep, base, end - base);
  namep[end - base] = 0;
  key.name = namep;

  opcode = htab_find (arm_ops_hsh, &key);

That's both less lucid and less efficient.  And it's not practical to
hide the mess in wrapper functions, because you have to get the type
of 'key' right ... gas/config/tc-arm.c has about a dozen little
structures stored in hash tables.

zw