similar to: [LLVMdev] Invalid or unaligned stack

On Tue, Mar 31, 2015 at 3:31 PM, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote: > Hi, > > I constructed a minimal Lua program that reproduces the problem. > Essentially the problem occurs if a JITed function is recursively > called - and there is a longjmp from the inner call. Example: > > function rais(n) > if n == 0 then error() > else rais(n-1) >

Hi On Windows 10 when using a debug build of LLVM 10, I get this assertion failure: Assertion failed: (KV.second.getFlags() & ~WeakFlags) == (I->second & ~WeakFlags) && "Resolving symbol with incorrect flags", file C:\work\github\llvm-10.0.0.src\lib\ExecutionEngine\Orc\Core.cpp, line 450 The same failure occurred in LLVM 9 too: Assertion failed: I->second ==

Are you using split stacks of some kind? Are you sure these actually work as intended on Win64? Based on the source code, it looks like you are allocating stack manually, but I could be wrong. What triple are you using with LLVM to generate code? There isn't much else information here, but you can try to zero in on the problem by checking the stack alignment manually with a helper like: void

Hi, I wrote sometime ago about this issue (see links below). http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/084089.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084193.html At the time I thought the problem was due to a bug in my code, and that I had fixed it. But sadly it seems that the issue is still present - it just got hidden by whatever change I made. The error only

Hi Praveen, On Sat, 10 Aug 2019 at 21:05, Praveen Velliengiri <praveenvelliengiri at gmail.com> wrote: > > Could you please send me your unoptimized and expected optimized code? The default implementation only contains some transformations. It would be helpful to know what you are actually trying. > Optimize Module is just a function object. > You can view the code here:

Hi Lang, On Tue, 13 Aug 2019 at 23:26, Lang Hames <lhames at gmail.com> wrote: >> I also get this message: >> JIT session error: Symbols not found: { raise_error } > > > Ahh -- I see the problem. The DynamicLibrarySearchGenerator is using the getAddressOfSymbol method, which (under the hood) is basically issuing an appropriate dlsym lookup, and that does not find

On 28 April 2015 at 00:30, Reid Kleckner <rnk at google.com> wrote: > I think Paweł identified the problem. The frames on the stack between the > setjmp and longjmp must have valid unwind information, which is described > here: > https://msdn.microsoft.com/en-us/library/ft9x1kdx.aspx?f=255&MSPPError=-2147217396 > > In particular, it has this line about JITed code: >

On 11 July 2015 at 13:14, Caldarale, Charles R <Chuck.Caldarale at unisys.com> wrote: >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On Behalf Of Dibyendu Majumdar >> Subject: [LLVMdev] JIT compilation 2-3 times slower in latest LLVM snapshot > >> I updated my clone of the LLVM github mirror today and I am finding >> that

Hi Lang, On Mon, 13 Apr 2020 at 19:12, Lang Hames <lhames at gmail.com> wrote: > >> I updated my project to LLVM 10.0 today and I am getting JIT symbol resolution errors. >> I could not find any example or updated tutorial or documentation that describes the new api - as all documentation seems out of date. > > > The doxygen comments should be up-to-date, as should

Hi Martin, On 25 September 2017 at 20:35, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Are you building a Debug or Release version of the compiler? It seems that in Release builds of LLVM 5.0 the dump() implementation is absent, although the method is available in the interface. This is plain wrong in my view. If the dump() has to be removed then it should not be present

Hi I updated my clone of the LLVM github mirror today and I am finding that the JIT compilation is now 2-3 times slower. The last time I refreshed was maybe 2 weeks ago. Is there a known change that would explain this? This is on Windows 8.1 64-bit. I am using MCJIT. Thanks and Regards Dibyendu

Hi Don, On 25 September 2017 at 22:37, Don Hinton <hintonda at gmail.com> wrote: > It'll work in release builds -- just rebuild llvm with LLVM_ENABLE_DUMP > enabled. > That assumes one has control over the LLVM build options. > On Mon, Sep 25, 2017 at 2:35 PM, Dibyendu Majumdar <mobile at majumdar.org.uk> > wrote: >> >> On 25 September 2017 at 22:29,

Hi, I am finding that my project that previously successfully built with versions 3.5 to 4.0 is now failing to link because of missing implementation for dump(). Errors I get are: Undefined symbols for architecture x86_64: "llvm::Type::dump() const", referenced from: ravi::LuaLLVMTypes::dump() in ravi_llvmtypes.cpp.o dump_content(lua_State*) in ravi_llvmluaapi.cpp.o

Hi, I am looking to port my MCJIT based implementation to ORC. I have been reading up on the ORC tutorials, but am not clear on how to do following: I would like to discard everything other than the compiled code after compiling a module. A module may have more than one function in it - so I would like to retain all the compiled functions. I am okay with eager compilation - i.e. there is no need

Hi Lang, On Tue, 13 Aug 2019 at 22:03, Lang Hames <lhames at gmail.com> wrote: > When you say your code is not getting optimized, do you mean that IR optimizations are not being applied, or that codegen optimizations are not being applied? > > What do you see if you dump the modules before/after running the pass manager on them, like this: > > dbgs() << "Before

Hi, I updated my project to LLVM 10.0 today and I am getting JIT symbol resolution errors. I could not find any example or updated tutorial or documentation that describes the new api - as all documentation seems out of date. I paste below some code snippets that show what I am doing: /* global syms is a array mapping names to function addresses */

Hi, I am upgrading my project from 3.7 to 3.8. I find that following code used to compile in 3.7 but doesn't in 3.8 and I can't understand why. llvm::Function *mainFunc = ...; auto argiter = mainFunc->arg_begin(); llvm::Value *arg1 = argiter++; arg1->setName("obj"); But if I change the code to following it compiles: auto argiter = mainFunc->arg_begin(); llvm::Value

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

Hi Martin On 25 September 2017 at 21:13, Martin J. O'Riordan <MartinO at theheart.ie> wrote: > Yes, if it is in the interface it would make more sense to have a null implementation at the very least. In my out-of-tree target, I also removed them from the interface if the build was for Release to ensure that I got compile-time errors to reveal other places I might have otherwise

Yes, if it is in the interface it would make more sense to have a null implementation at the very least. In my out-of-tree target, I also removed them from the interface if the build was for Release to ensure that I got compile-time errors to reveal other places I might have otherwise missed. All the best, MartinO -----Original Message----- From: Dibyendu Majumdar [mailto:mobile at