similar to: Errors linking with LLVM 5.0 - dump() missing

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

The dump() methods are only meant to be used in debuggers and are only available in debug builds of LLVM. There are often similar print() methods available though. - Matthias > On Sep 25, 2017, at 11:40 AM, Dibyendu Majumdar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, > > I am finding that my project that previously successfully built with > versions 3.5 to

Hi Matthias, On 25 September 2017 at 22:43, Matthias Braun <mbraun at apple.com> wrote: > The dump() methods are only meant to be used in debuggers and are only available in debug builds of LLVM. There are often similar print() methods available though. > I am not sure how this is the case seeing that the dump() function has been working in release builds in all the LLVM releases I

Hi Dibyendu, Are you building a Debug or Release version of the compiler? I had similar problems a few days ago when I was migrating to v5.0, and it turned out that I had calls to some of the dump routines that were not guarded by either 'DEBUG(...)' or '#ifndef NDEBUG ... #endif' and I was seeing the link failures with a Release build. These had been there since LLVM v3.1 and

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

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 88d207542b618ca6054b24491ddd67f8ca397540 Author: Matthias Braun <matze at braunis.de> Date: Sat Jan 28 02:02:38 2017 +0000 Cleanup

> On Sep 25, 2017, at 2:47 PM, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote: > > Hi Matthias, > > On 25 September 2017 at 22:43, Matthias Braun <mbraun at apple.com> wrote: >> The dump() methods are only meant to be used in debuggers and are only available in debug builds of LLVM. There are often similar print() methods available though. >> >

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

It'll work in release builds -- just rebuild llvm with LLVM_ENABLE_DUMP enabled. On Mon, Sep 25, 2017 at 2:35 PM, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote: > 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

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 22 February 2015 at 20:58, David Jones <djones at xtreme-eda.com> wrote: > Not sure if this is your problem, but it was mine: > > You must create (or obtain) a DataLayout *and install it into the Module*. > > It is possible to generate machine code for IR and not install the > DataLayout into the Module. Rather, the DataLayout is used locally at the > point where code

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