similar to: [FFI] [OrcJIT] Status update on C FFI for OrcJIT?

I didn't seen any roadmap and plan about OrcJit & MCJIT. And would OrcJIT be stablize in version 7.0? Or latter version? Would MCJIT be removed in source tree, when? -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo -------------- next part -------------- An HTML attachment was scrubbed... URL:

+ MLIR dev mailing list since that’s where the OrcJit I’m using is. Thanks for all the details, Lang! What you described is exactly what I’m looking for! Please, MLIR dev, let me know if this debug feature and the solution that Lang describes below is interesting for MLIR. I’ll dig more into the details then but it doesn’t seem too complicated. Thanks, Diego From: Lang Hames [mailto:lhames at

Hi Stefan Thank you! In case, you missed in llvm-dev listing: you can find the proposal here : link. <https://docs.google.com/document/d/1202EcXlWMQ8yxu5qD0b5fE0a_kihlcaPNpZo_Jk0YeQ/edit?usp=sharing> Thanks for working on summarising the Bugzilla tickets to track the recent changes in ORC this is really helpful. On Sat, 18 May 2019 at 21:33, Stefan Gränitz <stefan.graenitz at

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

Hello, I was wondering if there is someone already working on putting the new OrcJIT APIs in the LLVM-C bindings? Also, is there a general consensus to also add C bindings when new major features are added? Hayden -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150201/061f5949/attachment.html>

Hello everyone A previous thread about OrcJIT brought up bug reports on Bugzilla. A quick search gives 20+ results: https://bugs.llvm.org/buglist.cgi?component=OrcJIT&list_id=162232&query_format=advanced&resolution=--- While some of them are obviously outdated (addModuleSet API cleanup [1]), others may actually be relevant again (Small code model? [2]). If you reported one of them,

Thanks, David. I'd be happy to add the bindings .. is there a general way we add them? Or do you just scrub the API and make sensible judgements to the API? On Sun, Feb 1, 2015 at 1:55 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Sun, Feb 1, 2015 at 10:58 AM, Hayden Livingston <halivingston at gmail.com > > wrote: > >> Hello, >> >> I

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

Hi All, I'm back again after a couple of weeks hiatus, and I have some good news for anyone interested in cross-process JITing with OrcV2: The remote TargetProcessControl and Orc library breakup patch has landed in 1d0676b54c4 [1]. Thanks very much to Dave Blaikie and Stefan Graenitz for all their feedback on the review! As described in my last email, this commit breaks the OrcJIT library

Hi, I''ve been using FFI with a Ruby 1.9.3 built with MSVC++ and it''s been working well. One thing I''ve run into though is this: ffi_lib :msvcrt But that''s not the runtime I want. But I don''t want to hard code the runtime name either. I realize I could parse it out of RbConfig, but I was hoping for something nicer. Is there a way we could create an

Hi Sanjoy, >> (1) Replacing function bodies at the same address is impossible if the >> function is already on the stack: You'd be replacing a definition that >> you're later going to return through. > > If the function you wish to replace is active on the stack, you can > replace the return PC that was going to return into that active frame > with a PC

Hi, Try as I might, I just cannot get Dir.create_junction to work with FFI in the ffi branch of the win32-dir project. The problem is the REPARSE_JDATA_BUFFER struct. I''m just not sure how to set those members, specifically, the PathBuffer member. The target looks good, it''s UTF-16LE encoded, but I can''t make it work, despite trying several ways of defining the struct,

Hi all, I open sourced a small project of mine recently. It is an EDSL for C++ which makes just-in-time compilation much easier to write and maintain. One of its backends is LLVM's OrcJIT (LLVM 7, still). https://github.com/tetzank/coat Here is a blog post of mine introducing the concept: https://tetzank.github.io/posts/coat-edsl-for-codegen/ You can see it as an abstraction layer on top

Hello, I'm new to LLVM and I had a question about it: when we call the JIT::runFunction, since llvm doesn't has a full FFI, there are some cases in which the JIT needs to codegen a stub function to call the function we are interested, my question is: this stub function will remains in the module until when ? What are the most efficient way to remove it from the module and memory ? For a

Hi all, How does this look as a potential FFI for our theoretical Ruby++ ? I''m not sure how to do mixins, though. Some sort of special directive? Or just add it to inheritance chain? Anyway, this is just a rough prototype. No attempt at an actual implementation yet. Regards, Dan // foo.h - Function prototypes #define _FOO_H_ using namespace ruby; // Subclass Object class Foo :

While browsing the configure generated llvm/Config/config.h, I'm noticed that the macros: HAVE_FFI_CALL HAVE_FFI_FFI_H HAVE_FFI_H are not defined on OS X (currently 10.6.5). Given that ffi exists on this platform (both headers and lib), is this result intended? Thanks Garrison

Hi All, The attached patch (against r225842) contains some new JIT APIs that I've been working on. I'm going to start breaking it up, tidying it up, and submitting patches to llvm-commits soon, but while I'm working on that I thought I'd put the whole patch out for the curious to start playing around with and/or commenting on. The aim of these new APIs is to cleanly support a

Hello, I've been trying to use LLVM's Orc JIT from C API for a few days and i can't get it to work, I'm kind of annoyed for the lack of documentation examples for the C API. Here's my code: https://hasteb.in/ohexiweb.cpp I compile it using clang `llvm-config --cflags --ldflags --libs all` main.c -o main -g -rdynamic And it ends up segfaulting at the line where it calls

Hello LLVM-Mailing list, in the past I was using the MCJIT (if I understand it correctly) to load IR modules, compile them and execute them. The speciality of this JIT was, that it was writing the compiled code into a shared memory - for a different process to execute them. For that task the JIT used a 'custom' memory manager, memory mapping and also resolved undefined references itself.

Hi Armin, > The MCJIT API can only be used once to JIT compile external souces to excuteable code into the address space of a running process. I'm not sure exactly what you mean by "can only be used once" in this context. Regardless, the new APIs are definitely designed to make it easier to lead, unload and replace modules, and I hope they will support a wider range of use cases