search for: nikodemus

...* @foo, i32 0, i32 0), align 4 ret void } $ lli -jit-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 se...

...%res = trunc i64 %val0 to i32 ret i32 %res } Running this returns mostly 0, but sometimes 123. $ while sleep 1; do lli bug.ll; echo $?; done 123 0 0 0 123 0 0 Adding { alignstack=8 } to main makes it always return 123. Is this a bug or just a missing piece of documentation? Cheers, -- nikodemus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171105/a4fd8c46/attachment.html>

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) &g...

...with minimal case and llc.) What I can see in the debugger isn't immediately illuminating. Any clues? Am I missing the obvious here? This is: LLVM (http://llvm.org/): LLVM version 4.0.1 DEBUG build with assertions. Default target: i686-pc-windows-msvc Host CPU: skylake Cheers, -- nikodemus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171101/c45f5aaf/attachment.html>

...e if the relocation 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...

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

...*_module, t, true, // constant llvm::GlobalValue::ExternalLinkage, nullptr, // no initializer name); global = _module->getNamedGlobal(name); } return global; } Cheers, -- nikodemus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170530/372d8d64/attachment.html>

...<ga:@JazzFixnumClass> %EDX<def> = MOV32ri 123 RETL %EAX<kill>, %EDX<kill> Also, I have essentially identical code working perfectly fine when the memory being written to is from @alloca. I am completely clueless. Any suggestions most welcome. Cheers, -- nikodemus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170605/8c7c85cb/attachment.html>

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

..., i32 } @"__anonToplevel/1"() { entry: %0 = call { i8*, i32 } @getGlobal({ i8*, i32 }* nonnull @foo) ret { i8*, i32 } %0 } I'm at my wit's end. Any hints as to what I might be messing up would be much appreciated. I expect it is something ridiculously obvious... Cheers, -- nikodemus -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170604/0f211052/attachment.html>

...your use 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>&gt...

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

> 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