Re: move hash_any to utils/hash/hashfn.c

Hello

On 2019-Jan-25, Andres Freund wrote:

> I hate the current split quite a bit, albeit for somewhat different
> reasons. We make things like tag_hash, uint32_hash unnecessarily more
> expensive by adding an entirely useless external function call. And
> some of these can be fairly hot (e.g. for syscache). So yea, let's
> move this stuff together.

Here's a patch, but I haven't done anything that would change tag_hash
et al. Looking at the new hashfn.s, it looks like this:

tag_hash:
.LFB42:
.loc 1 681 0
.cfi_startproc
.LVL310:
.loc 1 682 0
call hash_any
.LVL311:
.loc 1 684 0
rep ret
.cfi_endproc

In master, it looks like this instead:

tag_hash:
.LFB96:
.loc 1 53 0
.cfi_startproc
.LVL5:
subq $8, %rsp
.cfi_def_cfa_offset 16
.loc 1 54 0
call hash_any(at)PLT
.LVL6:
.loc 1 56 0
addq $8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc

I don't know if the change is significant. Obviously we lost the
subq/addq (probably nothing to be excited about) but there's also the
@PLT in the call ... I don't know what that means.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services