similar to: [LLVMdev] LLVM C++ API memory management

On Nov 10, 2008, at 6:11 AM, Gregory Petrosyan wrote: > While reading LLVM API docs, I have noticed a lot of plain > "new"/"delete" > statements, and lots of bare pointers ("Value* = foo.getSomeValue()" > etc.). > > How exactly LLVM manages it's own memory? Who is responsible for > allocating/deallocating things? Why smart pointers are

Hi, I am new to LLVM, and I am pretty much paranoid about loose pointers. I would like to write a compiler in C++ + boost + llvm, but am worried about the pointers created and passed as parameters, especially about whose responsibility it is of deallocating them (does the LLVM API do it internally, or is it the application programmer's responsibility?). And what is the best practice for

Hi. I have a CentOS server (a Dell 860) with two drives in it. One is running CentOS 6.4 which I want to keep & the bigger 400GB drive has Debian 7 on it which I want to erase & use for backups. Which is the best way to go about achieving my intended goal? The Debian drive is not mounted when Centos is booted. Any help appreciated. Cheers, Phil... -- currently (ab)using Arch

On 14 Jan 2013, at 15:48, Reid Kleckner <rnk at google.com> wrote: > > Or maybe would it be possible to have a custom allocator for memory space for the native code that we could provide? With this last option we would be responsible for the clean up ourselves and just provide memory space to LLVM where it can store the results. > > Yes, you should be able to inherit from

On Fri, Jun 4, 2010 at 3:47 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Jun 4, 2010 at 2:46 AM, Gregory Petrosyan > <gregory.petrosyan at gmail.com> wrote: >> Hello, >> >> I am working on a pass that finds identical basic blocks and abstracts >> them into functions, in order to reduce code size. >> >> To decide, whether

> I'm trying to build LLVM 2.6 (from svn branch release_26) on cygwin > 1.7, and I have the following errors with both GCC 3.4.4 and GCC 4.3.4 > > llvm[2]: Linking Release Loadable Module profile_rt.dll Cygwin does not support dynamic linking (as any windows target). For the moment - you can just build tools and not the runtime via "make tools-only". -- With best

Hello, I am working on a pass that finds identical basic blocks and abstracts them into functions, in order to reduce code size. To decide, whether particular basic block group is worth factoring out, I want to estimate code size of some function that uses one of basic blocks in question 'as is', and after factoring the basic block into a new function. Can you please suggest a proper

Hi all, Is there any way to generate the binary code for a whole module at once? Currently I always get lazy compilation one function at a time. The reason I would like to generate the whole module at once is because I create some functions at run-time and then minimize the memory footprint by deallocating all LLVM objects. I've written my own JITMemoryManager to ensure that the binary

On Tue, Dec 8, 2009 at 8:26 PM, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> I'm trying to build LLVM 2.6 (from svn branch release_26) on cygwin >> 1.7, and I have the following errors with both GCC 3.4.4 and GCC 4.3.4 >> >> llvm[2]: Linking Release Loadable Module profile_rt.dll > Cygwin does not support dynamic linking (as any windows target).

This is what I get while trying to run 'make TEST=libcalls' in the top dir of test-suite: make[1]: Entering directory `/home/gregory/thesis/llvm/projects/test-suite/SingleSource' make[2]: Entering directory `/home/gregory/thesis/llvm/projects/test-suite/SingleSource/UnitTests' make[3]: Entering directory

On Fri, Jun 4, 2010 at 2:46 AM, Gregory Petrosyan <gregory.petrosyan at gmail.com> wrote: > Hello, > > I am working on a pass that finds identical basic blocks and abstracts > them into functions, in order to reduce code size. > > To decide, whether particular basic block group is worth factoring > out, I want to estimate code size of some function that uses one of >

Hi, I'm trying to build LLVM 2.6 (from svn branch release_26) on cygwin 1.7, and I have the following errors with both GCC 3.4.4 and GCC 4.3.4 llvm[2]: Linking Release Loadable Module profile_rt.dll /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: warning: cannot find entry symbol __cygwin_dll_entry at 12; defaulting to 62fc1000

Sure, you can turn off lazy compilation. Take a look at NoLazyCompilation in lli.cpp. Evan On Jul 7, 2008, at 6:08 AM, Nicolas Capens wrote: > Hi all, > > Is there any way to generate the binary code for a whole module at > once? Currently I always get lazy compilation one function at a time. > > The reason I would like to generate the whole module at once is >

On Tue, Jan 05, 2010 at 04:43:33PM +0300, Gregory Petrosyan wrote: > 'make TEST=example' works, 'make TEST=jit' and 'make' work too. Any ideas about what is going wrong here? No idea why this stuff was there... Index: TEST.libcalls.Makefile =================================================================== --- TEST.libcalls.Makefile (revision 92512) +++

Hi All, ORC's new concurrent compilation model generates some interesting lifetime and thread safety questions around LLVMContext: We need multiple LLVMContexts (one per module in the simplest case, but at least one per thread), and the lifetime of each context depends on the execution path of the JIT'd code. We would like to deallocate contexts once all modules associated with them have

Some additional info can be found at: http://murmurhash.googlepages.com/ http://en.wikipedia.org/wiki/MurmurHash http://www.codeproject.com/KB/recipes/hash_functions.aspx as well as in the patch description itself. Patch and benchmark attached. Gregory -------------- next part -------------- A non-text attachment was scrubbed... Name:

On Mon, Feb 08, 2010 at 10:31:23AM -0800, Chris Lattner wrote: > On Feb 7, 2010, at 1:03 PM, Gregory Petrosyan wrote: > > >On Sat, Feb 06, 2010 at 04:51:15PM -0800, Chandler Carruth wrote: > >>While I've not reviewed the patch in too much detail, it looks > >>promising. Can you run some end-to-end benchmarks to make sure that > >>cache pressure in the

There’s a few passes in LLVM that make heavy use of a big DenseMap, one that potentially gets filled with up to 1 entry for each instruction in the function. EarlyCSE is the best example, but Reassociate and MachineCSE have this to some degree as well (there might be others?). To put it simply: at least in my profile, EarlyCSE spends ~1/5 of its time growing DenseMaps. This is kind of… bad.

On Mon, 2007-12-03 at 18:56 -0800, Chris Lattner wrote: > Other IR objects (like instructions) have very simple ownership. An > instruction is owned by its basic block, a bb is owned by the function, a > function is owned by thet module. If an instruction is initially allocated with its Instruction *insertAtEnd parameter defaulted to null, and then later appended to a BasicBlock,

? Fri, 25 Oct 2024 15:03:54 -0500 fh at fharrell.com ?????: > Now I find that I can get rid of init.c, and change NAMESPACE to use > useDynLib(package name, list of compiled routine names) (without > .registration and .fixes) after making sure the Fortran and C > routines are not named the same as the package name. The routines > are called using .Fortran(binary module name,