search for: siivola

The docs are pretty vague about this. After digging into the examples I got the following to work with JIT to gain a pointer to variable elsewhere in the runtime, but I'd like to understand what is going on here, and if there is a, um, nicer API that I'm missing? llvm::Value* C::getGlobalVariable(const char* name, llvm::Type* t) {

...-kind=orc-mcjit -extra-module=jit-0.ll -extra-module=jit-1-clobber.ll main.ll; echo $? 13 $ lli -jit-kind=orc-mcjit -extra-module=jit-0.ll -extra-module=jit-1-noclobber.ll main.ll; echo $? 42 (Same happens with -jit-kind=mcjit.) Cheers, -- nikodemus On Wed, Jun 7, 2017 at 12:41 AM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > I just managed a quick experiment today to dump and load the definition of > the variable and the function that sets it into separate modules. > > ...loading those bitcode files into separate modules (and handing those > modules to JIT...

Solved by using alloca i8*, i32 2 which the system seems happy enough with, and bitcasting to the actual type for rest of the code after llvm.gcroot. Not entirely sure if this is a terrible workaround or exactly the way gcroot is supposed to be used... On Wed, Nov 1, 2017 at 11:59 AM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > I'm allocating { i8*, i32 } on the stack, and would like to add this as a > GC root, but I'm having trouble figuring this out. > > This works as expected: > > declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata) > >...

target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32" target triple = "i686-pc-windows-msvc" declare void @llvm.va_start(i8**) declare void @llvm.va_end(i8**) define i64 @foo(...) { %va = alloca i8*, i32 16 ; 4 words should be enough? call void @llvm.va_start(i8** %va) %x = va_arg i8** %va, i64 call void @llvm.va_end(i8** %va) ret i64 %x }

...case). I think when running 3rd party code, the only way to definitely avoid this kind of trouble is to never deallocate any code or data sections. Doug Binks mentioned that too in his cppcast about Runtime Compiled C++ http://cppcast.com/2016/05/doug-binks/ Am 21.11.17 um 14:20 schrieb Nikodemus Siivola via llvm-dev: > Transform the atexit into equivalent code you can control, run it > before the destructors of the JIT engine run? > > > On Tue, Nov 21, 2017 at 12:13 PM, Alex Denisov via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:...

...elocation is getting applied correctly in the context of your JIT? You may be able to repro this more easily using `lli`. It has a `-jit-kind` argument that should get you into the JIT codepath. (see test/ExecutionEngine/{MCJIT,ORCMCJIT}/) -- Sean Silva On Tue, Jun 6, 2017 at 1:09 AM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > This is on Windows 10: didn't yet manage to get a 64-bit toolchain set up > that agreed on everything necessary. > > Dumped bitcode, but when I did that everything landed in the same module > (normally the global is defined in a di...

I'm allocating { i8*, i32 } on the stack, and would like to add this as a GC root, but I'm having trouble figuring this out. This works as expected: declare void @llvm.gcroot(i8** %ptrloc, i8* %metadata) define i8* @bar(i8* %x) gc "shadow-stack" { entry: %objptr = alloca i8* call void @llvm.gcroot(i8** %objptr, i8* null) store i8* %x, i8** %objptr %v = load i8*, i8**

On Mon, Jun 5, 2017 at 1:34 PM, Nikodemus Siivola < nikodemus at random-state.net> wrote: > Uh. Turns out that if I hide the pointer to @foo from LLVM by passing it > through an opaque identity function ... then everything works fine. > > Is this a bug in LLVM or is there some magic involving globals I'm > misunderstandin...

...g 3rd party code, the only way to definitely avoid > this kind of trouble is to never deallocate any code or data sections. > Doug Binks mentioned that too in his cppcast about Runtime Compiled > C++ http://cppcast.com/2016/05/doug-binks/ > > Am 21.11.17 um 14:20 schrieb Nikodemus Siivola via llvm-dev: >> Transform the atexit into equivalent code you can control, run it >> before the destructors of the JIT engine run? >> >> >> On Tue, Nov 21, 2017 at 12:13 PM, Alex Denisov via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lis...

On 11 June 2017 at 07:53, David Blaikie <dblaikie at gmail.com> wrote: > Sounds like you're looking for reinterpret_cast: http://en. > cppreference.com/w/cpp/language/reinterpret_cast > I tried cast<ConstInt>(vo), but that failed at run-time. > > On Sun, Jun 11, 2017 at 3:06 AM Dipanjan Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: >

On 11 June 2017 at 11:32, Nikodemus Siivola <nikodemus at random-state.net> wrote: > On Sun, Jun 11, 2017 at 7:49 PM, Dipanjan Das via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On 11 June 2017 at 07:53, David Blaikie <dblaikie at gmail.com> wrote: >> >>> Sounds lik...

Since the getelementptrs were implicitly generated by the CreateStore/Load I'm not sure how to get access to them. So I hacked the assignment to be done thrice: once using a manual decomposition into two GEPs and stores, once using the "big" CreateStore, once via the setGlobal function, printing addresses and memory contents at each point to the degree that I have access to them.

> It's not the job of the Orc engine. I could argue about this, but I won’t :) > Just don't use atexit. The problem is that I run third-party programs. I cannot control them. > On 20. Nov 2017, at 01:04, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Nov 20, 2017 at 12:22:49AM +0100, Alex Denisov via llvm-dev wrote: >> JIT

Emitting calls to these functions (written in an .ll file linked in) works fine, and does the right thing. %Any = type { i8*, i32 } define dllexport void @setGlobal(%Any* %ptr, %Any %value) { store %Any %value, %Any* %ptr ret void } define dllexport %Any @getGlobal(%Any* %ptr) { %val = load %Any, %Any* %ptr ret %Any %val } Trying to replace the setGlobal call with what should be