guile-devel
[Top][All Lists]
Advanced

[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’.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]