[Bug c/71785] New: Computed gotos are mostly optimized away

[andres at anarazel dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785

            Bug ID: 71785
           Summary: Computed gotos are mostly optimized away
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andres at anarazel dot de
  Target Milestone: ---

Hi,

I'm working on some interpreter like constructs in postgres. To reduce the
number of mispredictions I wanted to use the "typical" jump threading approach.
Unfortunately with gcc-6 (gcc-6 (Debian 6.1.1-8) 6.1.1 20160630) and up to a
recent snapshot (Debian 20160612-1) 7.0.0 20160612 (experimental) [trunk
revision 237336]), gcc merges some of the gotos together in a common label, and
jumps there.

In the attached file (a small artifical case showing the problem), with -O3
this results in
CASE_OP_A:
        someglobal++;
        op++;
        goto *dispatch_table[op->opcode];
CASE_OP_B:
        do_stuff_b(op->arg);
        op++;
        goto *dispatch_table[op->opcode];

being implemented as
.L5:
        addq    $8, %rbx
        jmp     *%rax
...
.L3:
        movl    (%rbx), %eax
        addl    $1, someglobal(%rip)
        movq    dispatch_table.1772(,%rax,8), %rax
        jmp     .L5
...
.L4:
        movl    -4(%rbx), %edi
        call    do_stuff_b
        movl    (%rbx), %eax
        movq    dispatch_table.1772(,%rax,8), %rax
        jmp     .L5


I've tried -fno-gcse and -fno-crossjumping, and neither seems to fix the
problem.

It's also kind of weird how the load from the dispatch table is still performed
in the individual branches, just the final jmp *%rax happens in the common
location (L5 here).  In the actual case I'm fighting with gcc "inlines" the jmp
*%rax in one of the dispatches, but not in the other 8.

Any additional information I can provide?

Regards,

Andres