Re: Use static inline functions for Float <-> Datum conversions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Use static inline functions for Float <-> Datum conversions
Date: 2016-08-31 13:44:14
Message-ID: 18068.1472651054@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On 08/31/2016 02:38 PM, Tom Lane wrote:
>> I wonder whether there is a compiler-dependent way of avoiding the union
>> trick ... or maybe gcc is already smart enough that it doesn't matter?

> It seems to compile into a single instruction, so it can't get any
> better from a performance point of view.

Yeah, confirmed here. On my not-real-new gcc (version 4.4.7, which
ships with RHEL6), these test functions:

Datum
compare_int8(PG_FUNCTION_ARGS)
{
int64 x = PG_GETARG_INT64(0);
int64 y = PG_GETARG_INT64(1);

PG_RETURN_BOOL(x < y);
}

Datum
compare_float8(PG_FUNCTION_ARGS)
{
double x = PG_GETARG_FLOAT8(0);
double y = PG_GETARG_FLOAT8(1);

PG_RETURN_BOOL(x < y);
}

compile into this (at -O2):

compare_int8:
.cfi_startproc
movq 40(%rdi), %rax
cmpq %rax, 32(%rdi)
setl %al
movzbl %al, %eax
ret
.cfi_endproc

compare_float8:
.cfi_startproc
movsd 40(%rdi), %xmm0
xorl %eax, %eax
ucomisd 32(%rdi), %xmm0
seta %al
ret
.cfi_endproc

(Not sure why the compiler does the widening of the comparison result
differently, but it doesn't look like it matters.) Before this patch,
that looked like:

compare_float8:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq %rdi, %rbx
subq $16, %rsp
.cfi_def_cfa_offset 32
movq 32(%rdi), %rdi
call DatumGetFloat8
movq 40(%rbx), %rdi
movsd %xmm0, 8(%rsp)
call DatumGetFloat8
xorl %eax, %eax
ucomisd 8(%rsp), %xmm0
seta %al
addq $16, %rsp
.cfi_def_cfa_offset 16
popq %rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc

Nice.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2016-08-31 13:46:30 Re: autonomous transactions
Previous Message Craig Ringer 2016-08-31 13:43:28 Re: pg_sequence catalog