search for: trampolining

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 -------------- next part -------------- A non-text attachment was

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

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 compile I think, with not all

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.patch Type: text/x-diff Size: 8808 bytes Desc:

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:

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)

Dear LLVM-Mailing list (again), I still have another beginners question in my mind - thank you for your patience. Again I was playing around, but this time with llvm::Function. In an older question I learned, that I can replace a llvm::Function directly with an address. llvm::Function *function = mainModue->getFunction("puts"); function->replaceAllUsesWith(

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:

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:

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

Eli Friedman wrote: > Also, for lack of an intrinsic, there's a relatively easy workaround: > you can declare a global containing the correct size, then link in a > small 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

The address of the callee may be more than 2 GB away in memory, which cannot be encoded as an immediate offset in the call instruction. So, the value is first materialized with a mov instruction which can encode the immediate and then jumped to through a register. Reid On Tue, Feb 22, 2011 at 12:03 PM, Xin Tong Utoronto <x.tong at utoronto.ca> wrote: > I have a question on the LLVM JIT

On some machines, the 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

Hi Hayden, Dave's answer covers this pretty well. Neither Orc nor MCJIT currently reason about replacing function bodies. They may let you add duplicate definitions, but how they'll behave if you do that isn't specified in their contracts. They definitely won't replace old definitions unless you provide a custom memory manager that's rigged to lay new definitions down on top

Taking the address of a function inhibits optimisations for that function. Essentially any ABI changes are unavailable if we can't adjust the call site to match. The case of interest here is when a given function is called directly and indirectly, and we don't want the latter to impose a cost on the former. One approach to avoid the ABI constraint cost is to extract/outline the body of an

Fellow developers, I'm parallelizing loops to be called by pthread. The thread body that I pass to pthread_create looks like define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) parent_frame is pointer to shared variables in original function 0x00007f0de11c41f0: mov (%r10),%rax 0x00007f0de11c41f3: cmpl $0x63,(%rax) 0x00007f0de11c41f6: jg 0x7f0de11c420c

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 first did it: two intrinsics,

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

Hi, > I'm parallelizing loops to be called by pthread. The thread body that I pass > to pthread_create looks like > > define i8* @loop1({ i32*, i32* }* nest %parent_frame, i8* %arg) > parent_frame is pointer to shared variables in original function > > 0x00007f0de11c41f0: mov (%r10),%rax > 0x00007f0de11c41f3: cmpl $0x63,(%rax) > 0x00007f0de11c41f6: