similar to: [LLVMdev] JIT compilation 2-3 times slower in latest LLVM snapshot

If you could create a single executable with a repro, and publish them somewhere (both the old llvm and new one which is slower), we could look at it. It's hard to say otherwise unless someone truly knows of a change. I'm interested in looking at this, because my experience has been opposite, compile times improved for my compiler in the past month. So I'm inclined to understand what

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 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, I am trying out ORC v2 and facing some problems. I am using LLVM 8.0.1. I updated my ORC v1 implementation from 6.0 to 8.0 based on Kaleidoscope example (i.e. using Legacy classes) and that works fine. Now I am trying out ORC v2 apis, based on https://github.com/llvm-mirror/llvm/blob/master/examples/Kaleidoscope/BuildingAJIT/Chapter2/KaleidoscopeJIT.h. I have got it to compile and build.

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

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

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

On 22 February 2015 at 22:54, Hal Finkel <hfinkel at anl.gov> wrote: >> I tried setting the module's DataLayout to the engine's DataLayout. >> Don't see any improvement. >> The memcpy() is to perform a struct assign, so I tried replacing that >> with member by member store. >> But even then the loads are not being eliminated so I guess the >>

On 23 February 2015 at 01:29, Kamal Sharma <kgs1.rice at gmail.com> wrote: > Hi Dibyendu, > > It would be very helpful if you could post the original source code or > snippet. > That way, one can investigate deeper to understand the problem. > > Regards, > Kamal Sharma > Hi Kamal, Sure. I guess I ought to create a test that one can look in isolation. I am

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

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 Lang, On Tue, 13 Aug 2019 at 22:15, Lang Hames <lhames at gmail.com> wrote: > >> 1) Can 0 ever be a valid VModuleKey? How can one reliably detect an invalid VModuleKey? > > > I believe 0 was a valid VModuleKey in ORCv1. The assertion is checking the the VModuleKey is present in the LogicalDylibs map. That means that you have to have used that key in an addModule call,

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 am getting following assertion failure when attempting to remove a module. /llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:311: llvm::Error llvm::orc::LegacyCompileOnDemandLayer<BaseLayerT, CompileCallbackMgrT, IndirectStubsMgrT>::removeModule(llvm::orc::VModuleKey) [with BaseLayerT =

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 */