search for: levner

...ifferent from 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:...

...led 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 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 remembe...

...ert(S); // > <- _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 symb...

...->second.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 w...

...gt; 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 status. > > On Fri, 20 Dec 2019 at 18:39, 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...

...same way and 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 > runViaL...

...std::ifstream 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 symbol...

...on't understand... > > 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.....

...e, but cumbersome (the example is not up-to-date here) * Windows: I lost hope (haven't looked at it for a long time though) Best Stefan Am 13.07.18 um 21:00 schrieb Alex Denisov: > cc'ing Stefan Gränitz, he had some progress on this topic. > >> On 13. Jul 2018, at 18:39, Geoff Levner via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Greetings, LLVM wizards. >> >> I was just wondering if any progress has been made on this issue in the last few months (using gdb to debug a module compiled by Orc). I had to move to the Orc API in order to be able...

...request it to manifest that > function. In your old version, when/where/how did your frontend > generate LLVM IR for this function? I'd check that and then see why a > similar thing isn't happening in the new version. > > - Dave > > On Fri, Sep 13, 2019 at 8:03 AM Geoff Levner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > The short version: > > > > When I port our application from LLVM 7 to 8, some JIT-compiled code > > seems to break the implicit instanciation of C++ templates. That is, > > when I try to resolve...

...>::swap(std::basic_filebuf<char, std::char_traits<char> >&) Incidentally, if I call that STL swap() function in the application, to ensure it is in the process symbols, the second symbol is found, but the first is still undefined. > > On Aug 27, 2019 8:18 PM, "Geoff Levner via llvm-dev" <llvm-dev at lists.llvm.org> wrote: >> >> Greetings, LLVM wizards. >> >> We are using Clang and Orc JIT (v1) to compile and execute C++ code on the fly. If a C++ module calls functions from external libraries, we add them via DynamicLibrary::LoadLibr...

...rator work > 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...

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

...VIDIA/cuda-samples/blob/c4e2869a2becb4b6d9ce5f64914406bf5e239662/Samples/vectorAdd_nvrtc/vectorAdd.cpp and https://github.com/NVIDIA/cuda-samples/blob/c4e2869a2becb4b6d9ce5f64914406bf5e239662/Samples/simpleDrvRuntime/simpleDrvRuntime.cpp Hope that helps. -V On Thu, Nov 19, 2020 at 12:11 PM Geoff Levner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I have made a bit of progress... When compiling CUDA source code in > memory, the Compilation instance returned by Driver::BuildCompilation() > contains two clang Commands: one for the host and one for the CUDA device. > I can e...

...> > I think this is the right place to ask such questions. > Otherwise, feel free to ping me on #llvm (AlexDenisov) if you need some > hints on how to JIT native code using Orc APIs. > > I hope it helps. > > Cheers, > Alex. > > > On 14. Jun 2018, at 12:44, Geoff Levner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Greetings, LLVM wizards. > > > > I am using clang to compile a C++ module, and an ExecutionEngine (MCJIT) > to execute a function it defines. That works (or pretends to). However, if > I call the modu...

...ng a struct.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...

...htforward on 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 foun...

...obably a RuntimeDyld 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 m...

...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...

...th different names. If that is the > case, my "fix" should > > make this work. If not, I'm a little lost. We can always go the route of > Clang, simply type > > cast the function pointer, that is not great either though. > > > > On 8/10/20 10:24 AM, Geoff Levner wrote: > > Thanks, Joseph and Johannes. > > > > I have not merged in anything, I am using the code from the repository > > as is. What is this -debug-only option, and to whom would I pass it? I > > am running our own JIT application, which uses clang to compile > &g...