I don't think it's especially hard, but just not specifically unimplemented because nobody's had a strong need for it. There's probably some combinations of code models and machines that does happen to work (e.g. emutls+linux+large-code+large-data+no-PIC). Julia has some support for thread locals, but as a JIT in control of the language we currently try to generate better code than would otherwise happen (often bits of inline assembly that's more similar to the initial-exec model than a dynamic library would normally be able to use)—but also with more limitations on how it may be used and requiring some additional support from the runtime. On Fri, Dec 20, 2019 at 1:17 PM Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote:> Hi Jameson, > Why thread local support is hard to support in JITs? Whether Julia > supports Thread locals? If so, it would be very much helpful to know how. > > Thanks > > On Fri, 20 Dec 2019 at 23:31, Jameson Nash via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> This had also came up at llvm-devmtg briefly at the JIT roundtable. One >> of the collaborators on my project had started a patch years ago to >> implement some of it https://reviews.llvm.org/D8815, but then we went a >> different direction with TLS in our frontend and it became unnecessary. >> >> On Fri, Dec 20, 2019 at 12:36 PM David Blaikie via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> +Lang for visibility >>> >>> On Fri, Dec 20, 2019 at 5:09 AM Geoff Levner via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> I am in the process of porting our ORC code to ORC v2 and LLJIT. Now >>>> that I have worked around a problem getting global constructors to be >>>> called, everything seems to work unless a module declares a static >>>> thread-local variable. In that case I get a "JIT session error" saying that >>>> the symbol __emutls_v.xyz was not found (substitute the mangled >>>> variable name for "xyz"). >>>> >>>> Does that mean anything to anybody out there? >>>> >>>> (I don't know if it's relevant, but we are using LLVM 8, and we are >>>> using Clang to compile C++ modules that are all put into a single JITDylib.) >>>> >>>> Geoff >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> 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/20191220/b112b285/attachment.html>
Praveen Velliengiri via llvm-dev
2019-Dec-21 17:31 UTC
[llvm-dev] LLJIT vs. thread-local storage
Thanks Jameson. On Sat, 21 Dec 2019 at 02:29, Jameson Nash <vtjnash at gmail.com> wrote:> I don't think it's especially hard, but just not specifically > unimplemented because nobody's had a strong need for it. There's probably > some combinations of code models and machines that does happen to work > (e.g. emutls+linux+large-code+large-data+no-PIC). Julia has some support > for thread locals, but as a JIT in control of the language we currently try > to generate better code than would otherwise happen (often bits of inline > assembly that's more similar to the initial-exec model than a dynamic > library would normally be able to use)—but also with more limitations on > how it may be used and requiring some additional support from the runtime. > > On Fri, Dec 20, 2019 at 1:17 PM Praveen Velliengiri < > praveenvelliengiri at gmail.com> wrote: > >> Hi Jameson, >> Why thread local support is hard to support in JITs? Whether Julia >> supports Thread locals? If so, it would be very much helpful to know how. >> >> Thanks >> >> On Fri, 20 Dec 2019 at 23:31, Jameson Nash via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> This had also came up at llvm-devmtg briefly at the JIT roundtable. One >>> of the collaborators on my project had started a patch years ago to >>> implement some of it https://reviews.llvm.org/D8815, but then we went a >>> different direction with TLS in our frontend and it became unnecessary. >>> >>> On Fri, Dec 20, 2019 at 12:36 PM David Blaikie via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> +Lang for visibility >>>> >>>> On Fri, Dec 20, 2019 at 5:09 AM Geoff Levner via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>> I am in the process of porting our ORC code to ORC v2 and LLJIT. Now >>>>> that I have worked around a problem getting global constructors to be >>>>> called, everything seems to work unless a module declares a static >>>>> thread-local variable. In that case I get a "JIT session error" saying that >>>>> the symbol __emutls_v.xyz was not found (substitute the mangled >>>>> variable name for "xyz"). >>>>> >>>>> Does that mean anything to anybody out there? >>>>> >>>>> (I don't know if it's relevant, but we are using LLVM 8, and we are >>>>> using Clang to compile C++ modules that are all put into a single JITDylib.) >>>>> >>>>> Geoff >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org >>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>> _______________________________________________ >>> 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/20191221/af730a91/attachment.html>
So, picking up this thread again after the holidays (burp)... Is there any chance that ORC v2 will support thread-local variables in the foreseeable future? Is there some way of configuring it today to ensure they are handled correctly? Or are we better off sticking with ORC v1? On Fri, Dec 20, 2019 at 9:59 PM Jameson Nash via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I don't think it's especially hard, but just not specifically > unimplemented because nobody's had a strong need for it. There's probably > some combinations of code models and machines that does happen to work > (e.g. emutls+linux+large-code+large-data+no-PIC). Julia has some support > for thread locals, but as a JIT in control of the language we currently try > to generate better code than would otherwise happen (often bits of inline > assembly that's more similar to the initial-exec model than a dynamic > library would normally be able to use)—but also with more limitations on > how it may be used and requiring some additional support from the runtime. > > On Fri, Dec 20, 2019 at 1:17 PM Praveen Velliengiri < > praveenvelliengiri at gmail.com> wrote: > >> Hi Jameson, >> Why thread local support is hard to support in JITs? Whether Julia >> supports Thread locals? If so, it would be very much helpful to know how. >> >> Thanks >> >> On Fri, 20 Dec 2019 at 23:31, Jameson Nash via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> This had also came up at llvm-devmtg briefly at the JIT roundtable. One >>> of the collaborators on my project had started a patch years ago to >>> implement some of it https://reviews.llvm.org/D8815, but then we went a >>> different direction with TLS in our frontend and it became unnecessary. >>> >>> On Fri, Dec 20, 2019 at 12:36 PM David Blaikie via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> +Lang for visibility >>>> >>>> On Fri, Dec 20, 2019 at 5:09 AM Geoff Levner via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>> I am in the process of porting our ORC code to ORC v2 and LLJIT. Now >>>>> that I have worked around a problem getting global constructors to be >>>>> called, everything seems to work unless a module declares a static >>>>> thread-local variable. In that case I get a "JIT session error" saying that >>>>> the symbol __emutls_v.xyz was not found (substitute the mangled >>>>> variable name for "xyz"). >>>>> >>>>> Does that mean anything to anybody out there? >>>>> >>>>> (I don't know if it's relevant, but we are using LLVM 8, and we are >>>>> using Clang to compile C++ modules that are all put into a single JITDylib.) >>>>> >>>>> Geoff >>>>> >>>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200107/fe79f095/attachment.html>
David Blaikie via llvm-dev
2020-Jan-07 18:33 UTC
[llvm-dev] LLJIT vs. thread-local storage
(just adding Lang here for visibility) On Tue, Jan 7, 2020 at 2:29 AM Geoff Levner via llvm-dev < llvm-dev at lists.llvm.org> wrote:> So, picking up this thread again after the holidays (burp)... Is there any > chance that ORC v2 will support thread-local variables in the foreseeable > future? Is there some way of configuring it today to ensure they are > handled correctly? Or are we better off sticking with ORC v1? > > On Fri, Dec 20, 2019 at 9:59 PM Jameson Nash via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I don't think it's especially hard, but just not specifically >> unimplemented because nobody's had a strong need for it. There's probably >> some combinations of code models and machines that does happen to work >> (e.g. emutls+linux+large-code+large-data+no-PIC). Julia has some support >> for thread locals, but as a JIT in control of the language we currently try >> to generate better code than would otherwise happen (often bits of inline >> assembly that's more similar to the initial-exec model than a dynamic >> library would normally be able to use)—but also with more limitations on >> how it may be used and requiring some additional support from the runtime. >> >> On Fri, Dec 20, 2019 at 1:17 PM Praveen Velliengiri < >> praveenvelliengiri at gmail.com> wrote: >> >>> Hi Jameson, >>> Why thread local support is hard to support in JITs? Whether Julia >>> supports Thread locals? If so, it would be very much helpful to know how. >>> >>> Thanks >>> >>> On Fri, 20 Dec 2019 at 23:31, Jameson Nash via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> This had also came up at llvm-devmtg briefly at the JIT roundtable. One >>>> of the collaborators on my project had started a patch years ago to >>>> implement some of it https://reviews.llvm.org/D8815, but then we went >>>> a different direction with TLS in our frontend and it became unnecessary. >>>> >>>> On Fri, Dec 20, 2019 at 12:36 PM David Blaikie via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>> +Lang for visibility >>>>> >>>>> On Fri, Dec 20, 2019 at 5:09 AM Geoff Levner via llvm-dev < >>>>> llvm-dev at lists.llvm.org> wrote: >>>>> >>>>>> I am in the process of porting our ORC code to ORC v2 and LLJIT. Now >>>>>> that I have worked around a problem getting global constructors to be >>>>>> called, everything seems to work unless a module declares a static >>>>>> thread-local variable. In that case I get a "JIT session error" saying that >>>>>> the symbol __emutls_v.xyz was not found (substitute the mangled >>>>>> variable name for "xyz"). >>>>>> >>>>>> Does that mean anything to anybody out there? >>>>>> >>>>>> (I don't know if it's relevant, but we are using LLVM 8, and we are >>>>>> using Clang to compile C++ modules that are all put into a single JITDylib.) >>>>>> >>>>>> Geoff >>>>>> >>>>> _______________________________________________ > 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/20200107/34bab0e8/attachment.html>