[llvm-dev] ORC JIT Weekly #2 -- COFF COMDAT Constants and Emulated TLS

[Lang Hames via llvm-dev]

Hi Machiel,

I have requested that 84217ad6611 be merged into the LLVM 10 release branch
in http://llvm.org/PR44700. It's a low-risk fix, so I'm hopeful that it
will make it in.

-- Lang.

On Fri, Jan 24, 2020 at 8:06 AM Machiel van Hooren <jcmac at machiel.info>
wrote:

> I'm very pleased that PR40074/44337 has been squashed, great work! This
> means I can now use unmodified LLVM for my application and perhaps soon
> target a stable release. Will it be part of the LLVM 10 release?
>
> Machiel
> On 24-Jan-20 04:27, Lang Hames via llvm-dev wrote:
>
> 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@<bitval>. 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 <Name>, when emulated-tls is enabled we will
> produce at least one emulated-tls symbol: __emutls_v.<Name> (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.<Name>. 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
>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://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/20200128/5184c2e1/attachment.html>