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 test_func1.bc/test_func2.bc/test_func1_and_func2.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 test_func1.bc in my main JITDylib, but then, if I try to load the test_func2 IR module in the same Dylib, I get the following error:
Duplicate definition of symbol ‘??_7exception@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=x86_64-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.
test_func1_and_func2.bc (24.9 KB)
test_func2.bc (21.9 KB)
test_func1.ll (66.5 KB)
test_func1_and_func2.ll (83.8 KB)
test_func1.bc (21.9 KB)
test_func2.ll (67.7 KB)
exception3.lua (1.65 KB)
