similar to: [LLVMdev] Getting address of label in jitted code

On Jan 23, 2009, at 3:23 AM, Mark Shannon wrote: > Dan, > >> >> On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote: >> >>> Hi, >>> >>> I need to get the address of a label in jitted code. >>> (This is so that I can insert a jump into the machine code to resume >>> interpretation from compiled code) >> >> Hello, >>

On Jan 23, 2009, at 06:23, Mark Shannon wrote: >> On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote: >> >>> I need to get the address of a label in jitted code. (This is so >>> that I can insert a jump into the machine code to resume >>> interpretation from compiled code) >> >> What's your plan for restoring register and memory state? >

Dan Gohman wrote: > On Jan 23, 2009, at 3:23 AM, Mark Shannon wrote: > >> Dan, >> >>> On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote: >>> >>>> Hi, >>>> >>>> I need to get the address of a label in jitted code. >>>> (This is so that I can insert a jump into the machine code to resume >>>>

Hi, I need to get the address of a label in jitted code. (This is so that I can insert a jump into the machine code to resume interpretation from compiled code) I've tried using gcc's address of labels, but llvm just gives meaningless integers, not real addresses. I've had a look at llvm.dbg.stoppoint, but I don't see where the address actually get stored and the docs are really

Gordon Henriksen wrote: > On Jan 23, 2009, at 06:23, Mark Shannon wrote: > >>> On Jan 22, 2009, at 3:45 AM, Mark Shannon wrote: >>> >>>> I need to get the address of a label in jitted code. (This is so >>>> that I can insert a jump into the machine code to resume >>>> interpretation from compiled code) >>> What's your

On Jan 23, 2009, at 10:06 AM, Mark Shannon wrote: > Dan Gohman wrote: >> >> LLVM doesn't support taking the real address of a label. It may >> some day, but that won't by itself make it safe to jump into >> compiled code from separately-compiled code. To do that, you'd >> need to arrange some stable set of assumptions about the state >> of the

Hello, Nicolas. > Is there a way in llvm to get the address of a generated instruction? Or > somehow to fix the location of a label in the llvm code (something that > may look like a basic block perhaps) and get after the compilation the > address of this label? Maybe it's worth to use llvm.dbg.stoppoint? -- With best regards, Anton Korobeynikov. Faculty of Mathematics &

Hi Anton, Anton Korobeynikov wrote: > Maybe it's worth to use llvm.dbg.stoppoint? > > Do you have an example on how to use this intrinsic with the JIT? How can I get at compile time the address of the stoppoint? Thx, Nicolas

The following IR implements the following nested loop: for (int i = start ; i < end ; ++i ) for (int p = 0 ; p < 4 ; ++p ) a[i*4+p] = b[i*4+p] + c[i*4+p]; define void @main(i64 %arg0, i64 %arg1, i1 %arg2, i64 %arg3, float* noalias %arg4, float* noalias %arg5, float* noalias %arg6) { entrypoint: br i1 %arg2, label %L0, label %L1 L0:

Kenneth Uildriks <kennethuil at gmail.com> wrote: > As I see it, the context switching mechanism itself needs to know > where to point the stack register when switching.  The C routines take > an initial stack pointer when creating the context, and keep track of > it from there.  If we don't actually need to interoperate with > contexts created from the C routines, we have

On Sun, Apr 11, 2010 at 2:41 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Sun, Apr 11, 2010 at 4:09 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: >> Kenneth Uildriks <kennethuil at gmail.com> wrote: >>> As I see it, the context switching mechanism itself needs to know >>> where to point the stack register when switching.  The C

Hi Andrew, Andrew Haley wrote: > Here's my problem, which I raised on IRC: > > JIT::getPointerToFunction gets the address of the start of a function. > But how do I find out where the end of the function is? I need this > to register the function for profiling. > > varth said: aph, you need to intercept the "endFunctionBody" call on > the memory manager, it

Nicolas Geoffray wrote: > Hi Andrew, > > Andrew Haley wrote: >> Here's my problem, which I raised on IRC: >> >> JIT::getPointerToFunction gets the address of the start of a function. >> But how do I find out where the end of the function is? I need this >> to register the function for profiling. >> >> varth said: aph, you need to intercept

The loop vectorizer relies on cleanup passes to be run after it: from Transforms/IPO/PassManagerBuilder.cpp: // Add the various vectorization passes and relevant cleanup passes for // them since we are no longer in the middle of the main scalar pipeline. MPM.add(createLoopVectorizePass(DisableUnrollLoops)); MPM.add(createInstructionCombiningPass());

Here's my problem, which I raised on IRC: JIT::getPointerToFunction gets the address of the start of a function. But how do I find out where the end of the function is? I need this to register the function for profiling. varth said: aph, you need to intercept the "endFunctionBody" call on the memory manager, it will tell you the start pointer and the end pointer But how can I do

On Sun, Apr 11, 2010 at 10:07 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > I'll forward your next draft back to the stackless folks, unless you > want to pick up the thread with them. Their reply: http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4475 Instead of @llvm.getcontextstacktop(%context), they want @llvm.getcurrentstacktop() so that they can copy

Right now the functionality is available, sometimes, from the C standard library. But embedded environments (often running a limited standard library) and server environments would benefit heavily from a standard way to specify context switches within a single thread in the style of makecontext/swapcontext/setcontext, and built-in support for these operations would also open the way for

On Fri, Apr 16, 2010 at 9:30 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Sun, Apr 11, 2010 at 10:07 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: >> I'll forward your next draft back to the stackless folks, unless you >> want to pick up the thread with them. > > Their reply: http://thread.gmane.org/gmane.comp.python.stackless/4464/focus=4475

The instcombine pass cleans up a lot. Any idea why there are still shufflevector, insertelement, *and* bitcast (!!) etc. instructions left? The original loop is so clean, a textbook example I'd say. There is no need to shuffle anything.At least I don't see it. Frank vector.ph: ; preds = %L5 %broadcast.splatinsert1 = insertelement <4 x

On 3/6/12 5:28 PM, Joerg Sonnenberger wrote: > Advantage of using the latest address: one saved jmp per call. Per newly JITted call ;) > Advantage of using the initial address: easier G/C of intermediate > versions, less things to keep track of. I still think both versions require larger changes. When using the latest address, you have to keep track of all JITted functions per