search for: trampolines

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:

...route I should take? Pairing each trampoline BB to a symbol should make it visible and this MOVQ instruction I want possible? With that approach, my questions are: Do I need to make these symbols for the trampoline BBs as an IR opt pass, can I get away with it using a MachineModule Pass to add the trampolines per module (file) (so far I have only created BasicBlock, MachineBasicBlock, and MachineFunction passes)?? Do I need to make a separate custom section for these trampolines symbols, or can I just add them to the .text section? Thanks again for your reply. Sincerely, K Jelesnianski --------------...

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: <http://lists.llvm.org/pipermail/llvm-d...

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

...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, al...

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

...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 trampolines this lowers your execution cost (calls are direct rather than indirect), but increases your update cost (you have to update many callsites, rather than a single trampoline). Out of interest, why the desire to avoid trampolines? They do make life a lot easier here. :) Cheers, Lang. On Wed, Mar 18...

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

...e program (-no-lazy) so that the stub won't be generated, but gives the error: LLVM JIT requested to do lazy compilation of function '_Z41__static_initialization_and_destruction_0ii' when lazy compiles are disabled! Any ideas? Note, I had to compile lli with -z execstack in order for trampolines on the stack to work. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081031/682d11d7/attachment.html>

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 firs...

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

...g about the x86-32 case. There are no comments in the JIT stub code in this case, so I'm not sure which register it is using. The problem with x86-32 is that there are so few registers, and for some calling conventions there is only one spare call clobbered register available. This is used by trampolines, so if it's also used by JIT, which is almost surely the case, that will cause trouble. Even worse, it looks like the JIT is wrong even without trampolines, because for the C and X86_StdCall conventions it is ECX that is spare, while for X86_FastCall and Fast it is EAX. Yet the JIT always use...