similar to: [LLVMdev] Function calls only being JIT'd once by Kaleidoscope with MCJIT?

Oh - I know what this is. You were running this on Linux, right? On MacOS I think the symbol is getting double mangled while going through MCJIT::getSymbolAddress, hence the failure: The IR level foo function gets compiled to "_foo" in the object file, and then "_foo" gets mangled to "__foo" when we look it up. Linux doesn't do assembly level name-mangling, so

Cheers Lang! You were right, I was testing this on Linux. I was planning on committing these changes with the corresponding changes to the Kaleidoscope tutorial walk-through. Might be a bit of a surprise to have no explanation of what MCJITHelper and friends is doing. I'll try and make time to prepare some patches along these lines, as well as updating future chapters with the same fix.

On Tue, Apr 21, 2015 at 7:26 AM, Per Mildner <Per.Mildner at sics.se> wrote: > Charlie Turner <charlesturner7c5 <at> gmail.com> writes: > > > I was planning on committing these changes with the corresponding > > changes to the Kaleidoscope tutorial walk-through. Might be a bit of a > > surprise to have no explanation of what MCJITHelper and friends is

On Tue, Apr 21, 2015 at 3:07 PM, Lang Hames <lhames at gmail.com> wrote: > No progress since Charlie last looked at it. Sorry, I meant to refer to the issue Per Mildner mentioned regarding the tutorials not building due to RTTI - which I recall discussing with you & Eric, but don't know what came of it. > As Per suggested, it may be > worth adding an explicit #error, or at

Hi Dmitri, You might want to try replacing the call to JMM->invalidInstructionCache() with a call to TheExecutionEngine->finalizeObject(). If you are getting a non-NULL pointer from getPointerToFunction but it crashes when you try to call it, that is most likely because the memory for the generated code has not been marked as executable. That happens inside finalizeObject, which also

Hi all, I tried to modify Kaleidoscope Tutorial (toy.cpp from llvm/examples/Kaleidoscope/Chapter7, LLVM 3.3 release branch) in order to use MCJIT instead of JIT. I get segmentation fault when running toy.cpp with fibonacci example from the tutorial. My modified toy.cpp is in attachment and still works with JIT (when #define USE_MCJIT line is commented out). I read discussions regarding

Hi Dmitri, You're right. The lli code should be cleaned up. As David said, there was a time when the call to invalidate the instruction cache was necessary. It isn't necessary anymore. -Andy -----Original Message----- From: Dmitri Rubinstein [mailto:dmitri.rubinstein at googlemail.com] Sent: Tuesday, June 04, 2013 7:20 AM To: David Tweed Cc: Kaylor, Andrew; LLVM Dev Subject: Re:

HI Dibyendu, A single MCJIT instance can notionally manage multiple modules, but there are caveats (which I'm afraid I don't remember off the top of my head) that make it unattractive in practice. I believe most clients opt for something like the ExecutionEngine-per-Module model used in the Kaleidoscope tutorials. As Dave mentioned, I'm also working on some new JIT APIs (Orc) that

Hi, I am building a new JIT compiler for Lua (actually a derivative of Lua), and am planning to use LLVM for this. I have trying out some basic functions using LLVM 3.5.1. I have been puzzled by one aspect of the MCJIT versions of the Kaleidoscope sample, and would hugely appreciate some insight. Can a single MCJIT instance be used to manage several modules? Why is a separate MCJIT instance

Am 04.06.2013 16:05, schrieb David Tweed: > | I am curious about JMM->invalidInstructionCache(), which I found in > | lli.cpp implementation. lli.cpp contains also call finalizeObject(), I > | just overlooked it. lli.cpp calls finalizeObject(), which calls > | applyPermissions, which in turn calls invalidateInstructionCache. So why > | lli.cpp does call

Hi, I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm using MCJIT and

Hi all :) I'm new to llvm! I'm going through the kaleidoscope : compiling llvm IR to object code tutorial, code in the listings breaks and causes a segmentation fault. After some investigation through gdb, probably this constructor call, causing the segfault. |Program received signal SIGSEGV, Segmentation fault.|| ||0x00000000004afee0 in

Hi, I'm currently working my way through the tutorial with LLVM 3.9.1 on Windows (finished chapter 4) and stumbled over a few things which could be improved: - "LLVMContext" does not exist as a variable -> "TheContext" - Chapter 3: 5 times - Chapter 4: 1 time - Chapter 5: 4 times - Chapter 6: 2 times - Chapter 7: 2 times 3.4. Function Code

Hi David! Thanks for reaching out, the codegen part of the tutorial is fine, but when I try to generate the object code file, it throws segfault. Also please note that I'm using release build of llvm, actually I don't know whether that is the root cause or not. I also run through valgrind, it seems like a invalid read from stack. |||Error Summary: | |1 errors in context 1 of 1:

Hi Rob, You need to set attribute ReadOnly on the sin / cos functions, using Function::addFnAttr(Attribute) for example. Best regards, -- Arnaud de Grandmaison -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Rob Pieke Sent: Monday, November 15, 2010 11:41 AM To: llvmdev at cs.uiuc.edu Subject: [LLVMdev] Optimization of calls

Thanks for the pointers. Am I correct in assuming that putting the precompiled bitcode into a second module and linking (or using the object caches) would result in ordinary function calls, but would not be able to inline the functions? -- lg On Jan 21, 2014, at 11:55 AM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > I would say that the incompatibility is by design. Not

True, I care more about how fast the code runs than how long it takes to compile it. So if the symbolic approach enables better code generation, that is a very significant advantage from my perspective. Is there any example code or documentation you can point to for details about how to implement the symbolic approach? Is it similar to any of the versions of Kaleidoscope or any other extant

I'm using the gvn pass, not sure about basic-aa. I've copied the code as-is from http://llvm.org/docs/tutorial/LangImpl4.html#code and added "F->addFnAttr( Attribute::ReadOnly )" after "Function *F = Function::Create(FT, Function::ExternalLinkage, Name, TheModule)". The passes it sets up are: // Set up the optimizer pipeline. Start with registering info about

For what it's worth we did a similar thing, but overrode RTDyldMemoryManager directly This allowed us to control where the RAM was allocated too (e.g. guarantee it was in the low 4GB so we could use small memory model and avoid the mov rax, xxxxxxx; call rax code generated for x86)*, and also override findSymbol() to have the same behaviour as described in 4). --matt * later issues in not

Hi Philip, In terms of the overall idea, I like what your proposing. However, I want > to be very clear: you are not planning on removing any functionality from > the existing (fairly low level) MCJIT interface right? > To confirm - I have no plans to remove MCJIT. I don't want to change any behavior for existing clients. The new stuff is opt-in. > We've built our own