similar to: [LLVMdev] longjmp and JIT compiled code on Windows

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

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 On 64-bit Windows the lack of proper stack unwinding support causes crashes in JIT code generated by LLVM. I was wondering if it is possible to ask LLVM to generate 32-bit code - and if that would work within a 64-bit Windows application - i.e. the rest of the system will be 64-bit only the generated code will be 32-bit. I was also wondering if this would allow me to workaround the crashes due

You actually can mix 32 and 64 bit code in the same Windows process, but only with great effort. Fixing PR24233 is probably easier. :) We know how to generate the info, but we still have to get it registered... On Thu, Oct 29, 2015 at 2:19 PM, Lang Hames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Dibyendu, > > I'm not familiar with Windows at all, but I assume you

Hi, I am encountering a problem that I do not know how to debug. I would greatly appreciate any guidance on this issue. On Windows when I run Lua test cases from JITed code I am getting following error: Unhandled exception at 0x00007FFCEEEAC500 (ntdll.dll) in lua.exe: 0xC0000028: An invalid or unaligned stack was encountered during an unwind operation. This is happening when the Lua code is

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