search for: glevner

...om the internal structure then Orc v1 not just in > API level. > TLS support is not in ORC for a long time at least I'm aware of , Could > you please confirm that ORC v1 actually compiles and run the code with > Thread locals? > > On Fri, 20 Dec 2019 at 23:36, Geoff Levner <glevner at gmail.com> wrote: > >> And yet the same C++ code using thread-local variables works fine (or >> seems to) when compiled with Orc v1. Does the change to the Orc API really >> make thread-local storage more difficult? >> >> On Fri, Dec 20, 2019 at 3:52 PM Pravee...

...// > <- _ZNSt6vectorIfSaIfEE17_M_default_appendEm should be added here. > } else if (auto Err = Sym.takeError()) > return std::move(Err); > > Is that not happening? > > Cheers, > Lang. > > > On Mon, Sep 16, 2019 at 9:36 AM Geoff Levner <glevner at gmail.com> wrote: > >> I have found the cause of our problems with implicit template >> instantiation, and it looks to me like a bug in Orc JIT in LLVM 8. >> (Perhaps Lang could confirm?) >> >> We use createLegacyLookupResolver() to create our symbol resolver,...

...c v1. Does the change to the Orc API really make thread-local storage more difficult? On Fri, Dec 20, 2019 at 3:52 PM Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Oh, I think Linux don't have support for TLS. > > On Fri, 20 Dec 2019 at 20:19, Geoff Levner <glevner at gmail.com> wrote: > >> Argh. Thanks for the info. We're on Linux. >> >> On Fri, Dec 20, 2019 at 3:46 PM Praveen Velliengiri < >> praveenvelliengiri at gmail.com> wrote: >> >>> Hi Geoff, >>> Gathering from past, I remember that the O...

....getAddress() == 0) return JITSymbol(getSymbolMaterializer(Name), SymEntry->second.getFlags()); That works for me, but I am not sure it is the right way to do it... Perhaps somebody else has a better idea? Geoff On Mon, Sep 16, 2019 at 3:56 PM Geoff Levner <glevner at gmail.com> wrote: > > In my test case it seems my module does define the symbol for the > missing function template, with weak linkage. But when the module is > finalized, LegacyRTDyldObjectLinkingLayer fails to assign it an > address, for some reason. > > I will continue...

...> for ELF objects? They do. :) I've not tested StaticLibraryDefinitionGenerator extensively on Linux. but we have a regression test checking basic usage. If you run into any trouble at all please file a bug and assign it to me. -- Lang. On Mon, Sep 28, 2020 at 2:05 PM Geoff Levner <glevner at gmail.com> wrote: > We use LLJIT. Do addObjectFile() and StaticLibraryDefinitionGenerator > work for ELF objects? > > On Mon, Sep 28, 2020 at 10:57 PM Lang Hames <lhames at gmail.com> wrote: > > > > Hi Geoff, > > > >> Importing symbols into the JI...

...n MachO. It may be more involved for ELF, but I haven't had a chance to dig in to this yet. > > Steps (1) and (2) are mostly done. Step (3) shouldn't be too difficult. Step (4) will be the interesting part. > > -- Lang. > > On Mon, Sep 28, 2020 at 7:35 AM Geoff Levner <glevner at gmail.com> wrote: >> >> Hi JITters, >> >> I have some JIT-compiled C++ code that uses symbols from a DSO which >> uses C++14's thread support library. When I compile it I get the >> following error message: >> >> Symbols not found: [ __emutl...

...ntimeDyld bug: It's not great at error reporting. A few people in the community are working on an ELF/x86-64 implementation of JITLink at the moment -- Once we have that you should get small code model support and better error handling. -- Lang. On Fri, Oct 2, 2020 at 4:03 AM Geoff Levner <glevner at gmail.com> wrote: > StaticLibraryDefinitionGenerator works as promised on ELF archives! > > I have only encountered one problem. If a static library has not been > compiled with -fPIC and uses symbols from a shared library, LLJIT does not > complain, but the code may crash wit...

...am stream1, stream2; > stream1.swap(stream2); > return 0; > } > > I didn't get undefined symbols error. I used > DynamicLibrarySearchGenerator::GetForCurrentProcess API to make symbols > from STL visible to ORC JIT. > > On Tue, 27 Aug 2019 at 20:36, Geoff Levner <glevner at gmail.com> wrote: > >> On Tue, Aug 27, 2019 at 4:56 PM Praveen Velliengiri >> <praveenvelliengiri at gmail.com> wrote: >> > >> > HI >> > Did you run the static constructor and destructor? How did you make >> your process symbols visible to...

...nd it seemed to be working (code is a bit messy, > but you get the idea): > > https://github.com/mull-project/mull/blob/master/lib/CustomTestFramework/CustomTestRunner.cpp#L71 > > I hope it helps. > > Cheers, > Alex. > > > On 21. Jun 2018, at 09:27, Geoff Levner <glevner at gmail.com> wrote: > > > > When OrcMCJITReplacement is given a new module, it asks for the module's > constructors, gives them names like $static_ctor.0, $static_ctor.1, etc., > and saves the mangled names in a map. Later, to execute them, it uses > runViaLayer(), whic...

...derstand... > > What do you mean by "invent secret names"? If you don't need to JIT native > object files, but only bitcode, then MCJIT' approach should work. Just use > that "snippet" in your code :) > > > On 19. Jun 2018, at 17:54, Geoff Levner <glevner at gmail.com> wrote: > > > > On Alex's advice I am switching from MCJIT to the Orc API to compile and > execute functions. Starting from the new clang-interpreter example in the > source code (top of the tree!), I am able to execute my functions all > right... as long as...

...ithub.com/llvm/llvm-project/blob/5aa56b242951ab0f0181386ea58509f19b09206e/llvm/include/llvm/ExecutionEngine/Orc/ExecutionUtils.h#L361 [2] https://github.com/llvm/llvm-project/blob/e7549dafcd33ced4280a81ca1d1ee4cc78ed253f/llvm/tools/lli/lli.cpp#L968 On Mon, Sep 28, 2020 at 7:18 AM Geoff Levner <glevner at gmail.com> wrote: > Importing symbols into the JIT from an object file or static library...? > > On Mon, Sep 28, 2020 at 5:29 AM Lang Hames <lhames at gmail.com> wrote: > >> Hi Andres, >> >> A topic that I'd find interesting is what it'd take to ma...

....ident_t.21 to struct.ident_t) which solved the issues with the libomp test cases. I'm not sure why it's showing up in this case however. ________________________________ From: Johannes Doerfert <johannesdoerfert at gmail.com> Sent: Monday, August 10, 2020 1:07 PM To: Geoff Levner <glevner at gmail.com> Cc: Huber, Joseph <huberjn at ornl.gov>; Lang Hames <lhames at gmail.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [EXTERNAL] Re: Orc JIT v2 breaks OpenMP in 11.x branch? Ok, `struct.ident_t.21` looks like a "duplicate" of `struct.ident_t`, w...

Argh. Thanks for the info. We're on Linux. On Fri, Dec 20, 2019 at 3:46 PM Praveen Velliengiri < praveenvelliengiri at gmail.com> wrote: > Hi Geoff, > Gathering from past, I remember that the ORCv2 doesn't support thread > local variable but not sure what is the current status now. What platform > you are on? > CC'ed (Lang hames) he knows exactly what is the

...to this was to always attempt to typecast the function type found in the module to the one defined in OMPKinds.def. There should be some debug clauses there that will tell you the types it's finding if that's the issue. Joseph Huber ________________________________ From: Geoff Levner <glevner at gmail.com> Sent: Monday, August 10, 2020 4:34 AM To: Lang Hames <lhames at gmail.com> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Huber, Joseph <huberjn at ornl.gov> Subject: [EXTERNAL] Re: Orc JIT v2 breaks OpenMP in 11.x branch? Thanks, Lang. I think I have identified the...

Well, I agree the front end must be responsible for (not) instantiating the function templates. However the problem shows up only when JIT compiling, for some reason, and only with LLVM 8. Is there perhaps something else that needs to be done before resolving symbols, in addition to running constructors, to ensure that instantiated function templates are taken into account? Or perhaps there is

Hi JITters, I have some JIT-compiled C++ code that uses symbols from a DSO which uses C++14's thread support library. When I compile it I get the following error message: Symbols not found: [ __emutls_v._ZSt15__once_callable, __emutls_v._ZSt11__once_call ] Those seem to correspond to std::__once_callable and std::__once_call, which are indeed present in the C++ standard library. And I

...the module to the one defined in OMPKinds.def. There should be some debug clauses there that will tell you the types it's finding if that's the issue. > >>> > >>> Joseph Huber > >>> ________________________________ > >>> From: Geoff Levner <glevner at gmail.com> > >>> Sent: Monday, August 10, 2020 4:34 AM > >>> To: Lang Hames <lhames at gmail.com> > >>> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Huber, Joseph <huberjn at ornl.gov> > >>> Subject: [EXTERNAL] Re: Orc JIT v2 bre...

...ast the function type found in the module to the one defined in OMPKinds.def. There should be some debug clauses there that will tell you the types it's finding if that's the issue. > > > > Joseph Huber > > ________________________________ > > From: Geoff Levner <glevner at gmail.com> > > Sent: Monday, August 10, 2020 4:34 AM > > To: Lang Hames <lhames at gmail.com> > > Cc: llvm-dev <llvm-dev at lists.llvm.org>; Huber, Joseph <huberjn at ornl.gov> > > Subject: [EXTERNAL] Re: Orc JIT v2 breaks OpenMP in 11.x branch? >...

...ased on the stack trace and description my first guess would be a clang misconfiguration rather than a JIT bug. How is that clang invocation being made? Is it from inside a callback from ORC, or is it before you add your module to the JIT? -- Lang. On Mon, Aug 3, 2020 at 5:41 AM Geoff Levner <glevner at gmail.com> wrote: > Here, by the way, is the stack trace leading to the failed assertion. > Note #9: clang::CodeGen::CGOpenMPRuntime::emitForStaticFinish(). > > #0 0x00007fb70fa44870 in abort () from /usr/lib64/libc.so.6 > #1 0x00007fb70fa3c0e6 in __assert_fail_base () from...

...module) vs > e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128 (jit) > > Any suggestions as to what to do with the Module containing CUDA kernel > code, so that the host Module can invoke it? > > Geoff > > On Tue, Nov 17, 2020 at 6:39 PM Geoff Levner <glevner at gmail.com> wrote: > >> We have an application that allows the user to compile and execute C++ >> code on the fly, using Orc JIT v2, via the LLJIT class. And we would like >> to extend it to allow the user to provide CUDA source code as well, for GPU >> programming....