similar to: LLVM 3.8 change in function argument lists?

+llvm-dev > On 2016-Feb-09, at 12:54, Harris, Kevin <Kevin.Harris at unisys.com> wrote: > > Duncan, > Kevin Harris here, from Unisys. In our application, generating LLVM IR, we have several instances of code that looks like this: > > . . . > Value* pDS; > . . . > auto argIt = pFunc->arg_begin(); >

Hi, This is probably more of a standard C++ question instead of an actual LLVM question, but here it goes anyway. I'm trying to invoke the following constructor: CallInst::CallInst(Value *Func, InputIterator ArgBegin, InputIterator ArgEnd, const Twine &NameStr, BasicBlock *InsertAtEnd); My code is: using namespace llvm; void replaceByClone(Function *f, CallInst *I){ Function *clone =

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

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

Hi Don, On 25 September 2017 at 22:29, Don Hinton <hintonda at gmail.com> wrote: > Thanks for reporting this. > > Looks like this one was missed -- the declaration should have been #ifdef'd > away along with the definition. A quick grep indicates there are a number > of them that need to be fixed. > > Here's the original commit: > > commit

Hi, I am using the LLVM release_37 branch and have a strange issue. Please see the two IR outputs I have saved below: https://github.com/dibyendumajumdar/ravi/tree/master/ravi-tests/comp_issue The original.ll is the code I am generating. The aftercompiling.ll is the output from LLVM with opt level 0. The issue is that LLVM is deciding to remove the blocks with labels updatei and updatei.64

Hi Lang, On Tue, 13 Aug 2019 at 20:47, Lang Hames <lhames at gmail.com> wrote: > > Sorry for the delayed reply. Looks like you have figured out how to solve your issue already. Out of interest, what did you need to do? Do you have anything that you would like to see added to http://llvm.org/docs/ORCv2.html ? > Sorry my post was misleading. I figured out below which was part of the