[patchv3 2/2] Accelerate lookup_symbol_aux_objfile 85x

[Doug Evans]

Jan Kratochvil <jan.kratochvil@redhat.com> writes:

> On Fri, 24 Oct 2014 09:16:01 +0200, Doug Evans wrote:
>> This breaks an abstraction boundary, IWBN to preserve it.
>> [IOW, I look at dict_* as being an implementation detail of blocks.]
>> 
>> If we were to go this route (and apologies for the delay), can you
>> write a routine like lookup_block_symbol which does the above and call
>> that here instead?
>> 
>> lookup_block_symbol should live in block.c, not symtab.c.
>> That's where this new routine should go too.
>
> Done.
>
> For the 'slow.C' test the performance gain is even higher; but I have not
> re-benchmarked the 'non-trivial app':
> 	Command execution time: 26.540344 (cpu), 26.575254 (wall)
> 	->
> 	Command execution time: 0.310607 (cpu), 0.311062 (wall)
> 	 = 85x
>
> OK for check-in?
>
> No regressions on {x86_64,x86_64-m32,i686}-fedora21-linux-gnu native and in
> DWZ and in -fdebug-types-section modes.
>
>
> Thanks,
> Jan
> gdb/
> 2014-11-28  Jan Kratochvil  <jan.kratochvil@redhat.com>
>
> 	* block.c (block_lookup_symbol_primary): New function.
> 	* block.h (block_lookup_symbol_primary): New declaration.
> 	* symtab.c (lookup_symbol_in_objfile_symtabs): Assert BLOCK_INDEX.
> 	Call block_lookup_symbol_primary.

Hi.

I was reviewing all the callers of lookup_symbol_in_objfile_symtabs.

This patch assumes we're looping over all objfiles,
but some callers aren't.  e.g., lookup_symbol_in_objfile_from_linkage_name.
It seems like we'll need to make a copy of lookup_symbol_in_objfile_symtabs
and call that in lookup_symbol_in_objfile (plus I'd add some comments
to lookup_symbol_in_objfile warning the reader that included symtabs
are not searched).

I could be missing something though.