search for: trampolin

Hi! Attached patches split init.trampoline into adjust.trampoline and init.trampoline, like in gcc. As mentioned in the previous mail, I've not made a documentation patch, since I'm not sure about what the documented semantics of llvm.adjust.trampoline should be. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------...

Hi Sanjoy, the first and last patches look good (except that you didn't add any tests for the auto-upgrade functionality). Comments on the other two below. > Attached patches split init.trampoline into adjust.trampoline and > init.trampoline, like in gcc. > > As mentioned in the previous mail, I've not made a documentation > patch, since I'm not sure about what the documented semantics of > llvm.adjust.trampoline should be. Here's what the GCC docs say: @hook TA...

Hi Sanjoy, > Attached set of patches splits llvm.init.trampoline into an "init" > phase and an "adjust" phase, as discussed on the "Go on dragonegg" > thread. thanks for doing this. The patches look good, though the decomposition into individual patches is not that great (since things won't always work, in fact not even...

Hi! Attached set of patches splits llvm.init.trampoline into an "init" phase and an "adjust" phase, as discussed on the "Go on dragonegg" thread. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Split-intrinsics-and-DAG-nodes.pa...

Hi! Thank you for the detailed review. I've attached a new set of patches. -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-New-trampoline-intrinsics-for-LLVM.patch Type: text/x-diff Size: 16783 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110903/f3ced529/attachment.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-the-InstCombine-pass.p...

Hi! It seems I forgot to attach the patch that documentations the two new intrinsics. I've attached it here. Thanks! -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Documentation.patch Type: text/x-diff Size: 5722 bytes Desc: not available URL:

Dear Mr. Northover, Thank you for the quick reply. You are correct about the address-mode operands :) . I guess an important detail left out was that the basic block (call it A) that wants to calculate the address of the target stationary trampoline basic block (call it B) will be moved around in memory during run-time. Our earlier solution, before the feature was implemented to move around (A) is exactly as you explained using the following with a scratch reg: $ bin/llc -relocation-model=pic simple.ll -o - > [...] > leaq .L...

...puts" with the address 0xF - that is what I was taught and it is functional. I also noticed that you can do the same with a llvm::GlobalValue - as said I'm still a beginner. Now I wonder can I replace the use of a specific function with the address of an address? (I think this is called a trampoline) In C++ I know that I could use a function pointer instead of a function call to achieve this. So... Deriving from that knowledge I would have to create a function pointer with the same signature as the function I want to replace. Is this possible with the llvm JIT interface? Can I simply use tha...

Attached patches change how dragonegg lowers trampolines (for compatibility with Go). -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-the-trampolines-for-Go.patch Type: text/x-diff Size: 5108 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm...

I have a question on the LLVM JIT I did some brief memory reading one day and I found that a call to a non-library function is resolved by the X86CompilationCallback, but the X86CompilationCallback is reached through a trampoline. why can not the generated code jump to the X86CompilationCallback function directly ? 0x2b0a6a4d103b: mov $0x2b0a6a561010,%rax 0x2b0a6a4d1045: callq *%rax // call foo > > > ==> > > 0x2b0a6a561010: mov $0xa743a0,%r10 // some kind of...

I understand that we need to push the address to a register then branch using the register. But i am asking why there is a trampoline there such that a call to foo is first branched to an snippet and the snippet branches to the X86CompilationCallback. is this snippet necessary ? Thanks Xin On Tue, Feb 22, 2011 at 12:39 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: > The address of the callee may be more than...

...ll target-specific .bc with the definition right before code > generation. So why can't LLVM provide that global? I don't care whether it's a global, intrinsic, or whatever. If I have to provide it in my software, I'll have to track any changes that happen in LLVM-generated trampolines in the future. My point is that LLVM is unnecessarily requiring software that generates LLVM bitcode to know things about the target, which defeats the purpose of the "V" in LLVM. I should be able to generate a .bc file, and email it to someone, and they should be able to use it,...

...Xin Tong Utoronto <x.tong at utoronto.ca> wrote: > I have a question on the LLVM JIT > > I did some brief memory reading one day and I found that a call to a > non-library function is resolved by the X86CompilationCallback, but the > X86CompilationCallback is reached through a trampoline. why can not  the > generated code jump to the X86CompilationCallback function directly ? > >           0x2b0a6a4d103b: mov    $0x2b0a6a561010,%rax >           0x2b0a6a4d1045: callq  *%rax > // call foo >> >> >> ==> >> >> 0x2b0a6a561010: mov    $0xa7...

...he location at 0x40e does not point to the beginning of the EBDA. Rather, it points to the beginning of the BIOS-reserved area of the EBDA, while the option ROMs place their data below that segment. For this reason, 0x413 is actually a better source than 0x40e to get the location of the real-mode trampoline. But it is even better to fetch the information from the multiboot structure, where the boot loader has placed the data for us already. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> --- xen/arch/x86/boot/head.S | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions...

...turn through. So, if you want to replace functions at the same address you'll have to have some sort of safe-point concept where you know the function you want to replace isn't on the stack. (2) Replacing function bodies at the same address isn't the only way to avoid the overhead of a trampoline. I haven't implemented this yet, but I really want to add llvm.patchpoint support to Orc. In that case you can lay down your replacement definition at a different address, update all your callsites, then delete your old definition after you're done executing it. Relative to using trampolin...

...ith a direct call to the new function. This leaves us with two functions that have the same semantic effect: - One has its address taken, and may have external visibility. Just calls the other. - One does not have its address taken and has internal visibility Direct call sites to the outer wrapper/trampoline can be optimised to direct calls to the new internal function, leaving no net change other than enabling other optimisations. Uses of the address of the symbol are unchanged as the original function is still present. Indirect call sites now go through this trampoline to share the code. There'...

...1c420c 0x00007f0de11c41fc: mov 0x8(%r10),%rax 0x00007f0de11c4200: incl (%rax) 0x00007f0de11c4202: mov (%r10),%rax 0x00007f0de11c4205: incl (%rax) 0x00007f0de11c4207: jmpq 0x7f0de11c41f0 0x00007f0de11c420c: xor %rax,%rax 0x00007f0de11c420f: retq I use init_trampoline to generate code that sets up the static link: 0x00007fffee982316: mov $0x7f48e1a08fb0,%r11 0x00007fffee982320: mov $0x7fffee982330,%r10 the static link 0x00007fffee98232a: rex.WB jmpq *%r11 The program crashes in loop1 on the 2nd instruction. r10, which contain...

Hi Sanjoy, > Attached patches change how dragonegg lowers trampolines (for > compatibility with Go). I think the right approach is to add an llvm.adjust.trampoline intrinsic to LLVM (and change llvm.init.trampoline to not return a result). Then the dragonegg trampoline code will become trivial, and the Go problem will just Go away :) In fact this was how I fi...

Hi! > I think the right approach is to add an llvm.adjust.trampoline intrinsic > to LLVM (and change llvm.init.trampoline to not return a result). Then the Won't that break previous code that relies on the current llvm.init.trampoline? I can start work on this if that is not a problem. -- Sanjoy Das http://playingwithpointers.com

...8(%r10),%rax > 0x00007f0de11c4200: incl (%rax) > 0x00007f0de11c4202: mov (%r10),%rax > 0x00007f0de11c4205: incl (%rax) > 0x00007f0de11c4207: jmpq 0x7f0de11c41f0 > 0x00007f0de11c420c: xor %rax,%rax > 0x00007f0de11c420f: retq > > I use init_trampoline to generate code that sets up the static link: > > 0x00007fffee982316: mov $0x7f48e1a08fb0,%r11 > 0x00007fffee982320: mov $0x7fffee982330,%r10 the static > link > 0x00007fffee98232a: rex.WB jmpq *%r11 > > The program crashes in loop1 on the...