Heikki Linnakangas <hlinnaka@iki.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_startprocmovq 40(%rdi), %raxcmpq %rax, 32(%rdi)setl %almovzbl %al, %eaxret.cfi_endproc
compare_float8:.cfi_startprocmovsd 40(%rdi), %xmm0xorl %eax, %eaxucomisd 32(%rdi), %xmm0seta
%alret.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_startprocpushq %rbx.cfi_def_cfa_offset 16.cfi_offset 3, -16movq %rdi, %rbxsubq $16,
%rsp.cfi_def_cfa_offset32movq 32(%rdi), %rdicall DatumGetFloat8movq 40(%rbx), %rdimovsd %xmm0, 8(%rsp)call
DatumGetFloat8xorl %eax, %eaxucomisd 8(%rsp), %xmm0seta %aladdq $16, %rsp.cfi_def_cfa_offset 16popq
%rbx.cfi_def_cfa_offset8ret.cfi_endproc
Nice.
regards, tom lane
