[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Using labels-as-values on MacOS X
From: |
Ludovic Courtès |
Subject: |
Using labels-as-values on MacOS X |
Date: |
Fri, 25 May 2012 17:31:11 +0200 |
User-agent: |
Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.93 (gnu/linux) |
Hi,
Ken Raeburn <address@hidden> skribis:
> * Don't use addresses of code labels with LLVM, even if the compiler
> supports them. At least with the version of LLVM GCC on my Mac ("gcc
> version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
> 2336.1.00)"),
Damn, what compiler is this? It’s not the old GCC 4.2 fork? Is it
Clang? GCC with DragonEgg?
> the performance seems to be quite poor; "guild compile" was showing
> about a 4x penalty in CPU time. (For psyntax-pp.go, it was 10 minutes
> of CPU time vs 46 minutes.)
Weird, would be good to see what happens.
The two options for VM dispatching are:
#include <stdio.h>
int
vm_jt (const unsigned int *code)
{
static const void *jump_table[] = { &&op0, &&op1, &&op2 };
register const unsigned int *ip = code;
#define NEXT goto *jump_table[*ip++]
NEXT;
op0:
puts ("op0");
return 0;
op1:
puts ("op1");
NEXT;
op2:
puts ("op2");
NEXT;
}
int
vm_switch (const unsigned int *code)
{
register const unsigned int *ip = code;
while (1)
switch (*ip++)
{
case 0:
puts ("op0");
return 0;
case 1:
puts ("op1");
break;
case 2:
puts ("op2");
break;
}
}
Could you look at the code generated by that compiler for this file?
With GCC 4.6.2 at -O2, the dispatch with labels-as-values looks like this:
mov -4(%rbx), %eax
movq jump_table.2080(,%rax,8), %rax
addq $4, %rbx
jmp *%rax
In the other case it’s a series of comparisons like this:
cmpl $2, %eax
jne .L14
movl $.LC2, %edi
call puts
movl (%rbx), %eax
addq $4, %rbx
cmpl $1, %eax
jne .L16
movl $.LC1, %edi
call puts
jmp .L14
> Later/future versions may do better, so we can update it with
> version-number checks, unless we want to build performance tests into
> the configure script, which doesn't sound like a great idea to me.
Agreed, but OTOH #ifdef __LLVM__ isn’t future-proof.
Thanks,
Ludo’.