similar to: [RFC] Cheaper indirect calls via trampolines

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

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(

Hi Again, I'm a little confused regarding what is the exact Orc's functions I should use in order to save the functions code in a code cache so it could be later replaced with different versions of it and I appreciate your help. Just a reminder I want to dynamically recompile the program based on profile collected at the run-time. I would like to start executing the program from the

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)

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:

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

On Thu, Jun 25, 2020 at 01:04:29PM +0300, Dan Carpenter wrote: > On Wed, Jun 24, 2020 at 12:39:24PM -0700, Kees Cook wrote: > > On Wed, Jun 24, 2020 at 07:51:48PM +0300, Dan Carpenter wrote: > > > In Debian testing the initrd triggers the warning. > > > > > > [ 34.529809] process '/usr/bin/fstype' started with executable stack > > > >

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:

This reverts commit 9d8d648e604026b32cad00a84ed6c29cbd157641, which broke signal handing on some architectures. On m68k and parisc, signal return depends on a trampoline that the kernel writes on the stack. On alpha, s390, and sparc (32-bit), we can avoid this by providing our own function as sa_restorer, but we currently don't. Signed-off-by: Ben Hutchings <ben at decadent.org.uk>

Dear All, I am working on a x86 backend machineFunction pass, where I am trying to save the hard coded address of an arbitrary machine basic block to memory in ASM. I know the assembly needed for this but am lost at how to construct the BuildMI(). Note that these machine basic blocks are not entry's to a function. but in the middle of the function. so using addGlobalAddress or

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

Duncan Sands wrote: > is it important for you to have portable bitcode (i.e. the trampoline > size as some kind of symbolic constant, maybe via a global or an > intrinsic) that works on all targets or would it be enough to have the > LLVM info for the target expose the trampoline size, so when generating > IR for a target X you would query the method for target X and if it

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 Gael I am sorry that I couldn't explain what I was trying to say, anyway I've got the answer :) . In the *parseFunction* method returns *llvmfunction* pointer of compiled method and then it will be stored in to cache. Could you please more elaborate on how those machine instructions ( native functions) executing by llvm. I was trying trace and I couldn't able to find

I've been playing with OrcJIT a bit, and from the looks of it I can (like in the previous JIT I suppose?) ask for a function to be re generated. If I've given the address of the function that LLVM gave me to an external party, do "I" need to ensure thread-safety? Or is it safe to ask OrcJIT to re generate code at that address and everything will work magically? I'm

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

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:

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: