Hi All,
This week I’ve been focused on removing some of the blockers for people transitioning from ORCv1 to ORCv2.
Issue #1 (http://llvm.org/PR40074, http://llvm.org/PR44337):
When LLVM codegens floating point constants for COFF we produce named constant pool entries of the form __real@. These are stored in COFF COMDAT sections [1] which allow duplicate symbol definitions to be discarded (roughly equivalent to the concept of a weak symbol). This posed two problems: (1) ORC had no idea about the (rough) mapping between COMDAT and Weak, and (2) did not support late introduction of weak symbols via MaterializationResponsibility::defineMaterializing. This caused use of the same floating point constant in multiple files to result in duplicate definition errors for the constant pool entries.
Both issues have been addressed in 84217ad6611, and floating point constants should now work in COFF. If you run in to any trouble with them please file a bug and CC me.
Issue #2: Emulated TLS and name mangling (raised by Geoff Levner on llvm-dev):
Use of emulated-tls affects the name mangling of LLVM IR symbols. For a thread local symbol with name , when emulated-tls is enabled we will produce at least one emulated-tls symbol: __emutls_v. (which must then be linker-mangled to get the final symbol name). If that symbol has a non-zero initializer a second symbol will also be produced: __emutls_t.. ORCv2 requires up-front specification of the exact set of linker-level symbol names that a module produces, so that it can dispatch and track compiles, however none of the existing mangling code took emulated-tls into account. This has been fixed in ce2207abaf9 (with follow up fixes for the various examples I broke), and you should now be able to use thread-locals in ORCv2.
Besides these two bugs, I have continued work on the big static initializer patch. Unfortunately issue #2 interacts with it, so I have to do some integration work before it is ready to land, but I’m hopeful that it will be ready some time next week.
Finally, I have added a new example (bb7a5707ac0)to llvm/examples/LLJITExamples: LLJITWithObjectLinkingLayerPlugin demonstrating how to write a custom ObjectLinkingLayer plugin. ObjectLinkingLayer plugins can be used to receive and respond to events in the linking layer, and to inspect and modify JITLink LinkGraphs during the linking process. ORC uses this internally to register EH frames, but the system is likely to be of interest to anyone who wants low level control/visibility into the JIT linker.
— Lang.
[1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#comdat-sections-object-only
