I suspect it does this because of instruction alignment and pipelining issues. Why are you trying to turn off alignment? You might try adding a nop after each one. --Dean On Tue, 1 Sep 2009, Robert Bernecky wrote: > I'm trying to get gcc version 4.3.2 to emit X86-64 code > fragments that I can catenate to perform my own JIT > compilation, but the compiler is being recalcitrant. > > (I was using a jump table, but its performance was underwhelming.) > > Roughly, what I've done is to create a set of code fragments, > with labels so that I can determine their address ( via &&label) > and length. E.g., > > topLoad1: reg1 = x[i]; > botLoad1: > > topLoad2: reg2 = y[i]; > botLoad2: > > topAdd: regz = reg1 + reg2; > BotAdd: > > topStore: z[i] = regz; > botStore: > > Then, I have a table of fragment addresses (topLoad1, topLoad2, etc.) > and lengths (botLoad1-topLoad1, botLoad2-topLoad2), and a > (unknown statically) list of fragments to be assembled to build > working code, e.g.: > > (Load2, Load1, Add, Store, Loop) > > I assemble the fragments into a code buffer and jump to it, > or so the story goes. Unfortunately, what I'm seeing in the > generated code fragments is not fun: > > 1. GCC sometimes, but NOT always, inserts jumps to the next > fragment. E.g.: > > ---------------------------------------------- > > .L46: > .loc 2 34 0 > movq -264(%rbp), %rax > movq %rax, -40(%rbp) > .L47: > .L7: > .loc 2 40 0 > movl %r8d, %eax > jmp .L48 > .L6: > .L48: > .loc 2 43 0 > movl %r11d, %ecx > .L49: > .L50: > ---------------------------------------------- > > Note the jmp .L48. If GCC always inserted a jump, I could > remove it, or if it never inserted the jump, I'd be even > happier, but it only does it now and then. I tried adding > my own jumps to force this: > > topLoad2: reg2 = y[i]; > goto botLoad2; > botLoad2: > > but GCC removed them. And inserted others. > > Today, I'm using these compiler options: > > gcc -O0 -ggdb -mtune=opteron -fno-align-labels -fno-align-jumps > > So, I welcome suggestions on how to solve or work around these > problems. Or even a completely different approach. > > Thanks, > Robert > > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 256 5494
