[llvm-dev] C++ JIT Compiler with LLVM on Windows 10 (original) (raw)

Lang Hames via llvm-dev llvm-dev at lists.llvm.org
Tue May 5 11:12:08 PDT 2020

Hi Emmanuel,

Thank you very much for these! I will check them out today and see what's going on.

Regards, Lang.

On Mon, Apr 27, 2020 at 8:35 PM Emmanuel Roche <roche.emmanuel at gmail.com> wrote:

Hi Lang,

Thank you for your feedback on the blog post, please find below some additional inputs from my side on the comments you provided: > Regarding emulated TLS deactivation: I've never looking into how/whether this works on Windows. If it doesn't make sense to have it on by default there we can change the default for Windows targets. I'm really no expert, so you probably want to collect additional inputs/checks on this point, but yes, from my current perspective, it seems that it doesn't really work to try to use Emulated TLS in LLJIT on Windows, but one should keep in mind that this is when using the microsoft crt from Visual Studio (FYI, I'm using version 2017 for now, maybe it was different in previous versions too): I would expect things to be different if you are using another compiler as base (?) [I mean, if you change the default, this might then break previously working code that was based on mingw for instance... But not sure if this should be a concern or not for a not yet released version of LLVM ;-)] > I think that anything that llvm-link can merge should, in theory, be safe to add to the JIT. This actually sounds like a bug. Are you able to share the full modules that you were merging? Initially, the test I made on this point was using the Lest test framework as described in my post, but your feedback above got me thinking, and I could actually come up with a more simple setup without any C++ library dependency: this new test is simply based on a couple of C++ functions that are using exceptions. I used the attached lua script "exception3.lua" to generate the bitcode files and load the corresponding modules [of course I don't expect you to run lua scripts, but I thought that this could help understanding the code generation context anyway]. So with that script I generated the testfunc1.bc/testfunc2.bc/testfunc1andfunc2.bc and the corresponding .ll file (generated from the .bc files using llvm-dis): all those files are attached to this email too. => So, I can load for instance the module corresponding to testfunc1.bc in my main JITDylib, but then, if I try to load the testfunc2 IR module in the same Dylib, I get the following error: Duplicate definition of symbol '??7exception at std@@6B@' In all the .ll files you will find multiple references of that symbol... but unfortunately, my skills won't get me any further than that [=> ie. I have no idea what to think about the content of those files :-)]. But anyway, if you notice anything interesting yourself, or you have an idea you think I should try, or you need more info on anything here please let me know. PS: I'm thinking maybe the command line arguments I'm providing to the compilerInvocation might also be important here so, just in case: here is the list of args I'm using currently: { "-triple=x8664-pc-windows-msvc19.16.27030", "-x", "c++", "-mrelax-all", "-mincremental-linker-compatible", "-disable-free", "-discard-value-names", "-mrelocation-model", "pic", "-pic-level", "2", "-mthread-model", "posix", "-mframe-pointer=none", "-relaxed-aliasing", "-fmath-errno", "-fno-rounding-math", "-mconstructor-aliases", "-munwind-tables", "-target-cpu", "x86-64", "-mllvm", "-x86-asm-syntax=intel", "-stack-protector","2", "-fcxx-exceptions", "-fexceptions", "-fexternc-nounwind", "-fms-volatile", "-fdiagnostics-format", "msvc", "-dwarf-column-info", "-Wall", "-std=c++17", "-fdeprecated-macro", "-ferror-limit","19", "-fmessage-length=174", "-fms-extensions", "-fms-compatibility", "-fms-compatibility-version=19.16.27030", "-fdelayed-template-parsing", "-fcolor-diagnostics", "-fobjc-runtime=gcc", "-faddrsig", } Regards, Manu.

Le lun. 27 avr. 2020 à 20:41, Lang Hames <lhames at gmail.com> a écrit : I was just reading the blog post -- very cool!

Regarding Globals construction & destruction: There definitely has been a lot of churn in that area. There will probably be more before LLVM 11 is released, but I can see light at the end of the tunnel. I think the Right Way to run initializers in a JITDylib is to treat it as equivalent to a dlopen operation (with extra allowances for the fact that new initializers can be added to a JITDylib at runtime). This is what the LLJIT::initialize method is doing. Now we just need to generalize it to support out-of-process JITs. That will at least require a new remote-target abstraction, and an RPC implementation for testing in-tree. Regarding emulated TLS deactivation: I've never looking into how/whether this works on Windows. If it doesn't make sense to have it on by default there we can change the default for Windows targets. Regarding merging of multiple modules: "But of course this would not work because as soon as I try to load the second script, I get a duplicate symbol error from LLVM (and this completely makes sense): [ERROR]: LLVM error: Duplicate definition of symbol '??7success at lest @@6B@'" I think that anything that llvm-link can merge should, in theory, be safe to add to the JIT. This actually sounds like a bug. Are you able to share the full modules that you were merging? Regards, Lang.

On Mon, Apr 27, 2020 at 11:11 AM David Blaikie <dblaikie at gmail.com> wrote: +Lang for LLVM Orc things On Mon, Apr 27, 2020 at 3:34 AM Emmanuel Roche via llvm-dev <_ _llvm-dev at lists.llvm.org> wrote:

Hello LLVM developers!

So, I'm continuing my journey with my toy C++ JIT compiler implementation, and I wrote another article on the issues/solutions I've been working on in the past few days, mainly: - Precompiled header handling, - Emulated TLS desactivation, - Globals construction & destruction, - C++ exceptions handling, - Multi modules linking, => In case this could be helpful to anyone, you will find this article here: http://wiki.nervtech.org/doku.php?id=blog:2020:0425jitcompilerpart5improvements And of course, if you have any questions for me, just let me know. Meanwhile, happy hacking everyone ;-)! Best regards, Manu.

LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200505/5a0906db/attachment.html>

More information about the llvm-dev mailing list