Re: Using labels-as-values on MacOS X
Hi, Hans Aberg haber...@telia.com skribis: On 25 May 2012, at 17:31, Ludovic Courtès wrote: Ken Raeburn raeb...@raeburn.org 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? $ /usr/bin/gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00) $ ls -l /usr/bin/gcc lrwxr-xr-x 1 root wheel 12 Mar 23 21:20 /usr/bin/gcc - llvm-gcc-4.2 They put so much effort into making a compiler indistinguishable from GCC that all we can hope for is that it generates code that performs as well as GCC’s. I wouldn’t want to #ifdef around these shameless hacks. Thanks for the info! Ludo’.
Re: Using labels-as-values on MacOS X
On 26 May 2012, at 14:44, Ludovic Courtès wrote: Hans Aberg haber...@telia.com skribis: On 25 May 2012, at 17:31, Ludovic Courtès wrote: Ken Raeburn raeb...@raeburn.org 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? $ /usr/bin/gcc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00) $ ls -l /usr/bin/gcc lrwxr-xr-x 1 root wheel 12 Mar 23 21:20 /usr/bin/gcc - llvm-gcc-4.2 They put so much effort into making a compiler indistinguishable from GCC that all we can hope for is that it generates code that performs as well as GCC’s. I wouldn’t want to #ifdef around these shameless hacks. When compiling packages, I normally use /usr/bin/gcc, which is llvm-gcc then, because I think it was what package writer normally would expect. So 'configure' normally chooses gcc, which then becomes llvm-gcc unless one is doing something, like setting CC or installing ones own GCC. Otherwise, the system compiler is now actually clang: $ ls -l /usr/bin/cc /usr/bin/cc - clang Before it was LLVM-GCC which still has a link from /usr/bin/gcc. Thanks for the info! You are welcome. Hans
Using labels-as-values on MacOS X
Hi,
Ken Raeburn raeb...@raeburn.org 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
movqjump_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
callputs
movl(%rbx), %eax
addq$4, %rbx
cmpl$1, %eax
jne .L16
movl$.LC1, %edi
callputs
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’.
