similar to: [LLVMdev] malloc vs malloc

On Dec 23, 2008, at 9:14 AM, Jon Harrop wrote: > I discovered that LLVM's malloc only allows a 32-bit size argument, > so you > cannot use it to allocate huge blocks on 64-bit machines. So I > considered > replacing all of my uses of LLVM's malloc instruction with calls to > the libc > malloc function instead. That got me wondering why LLVM even has its >

Chris Lattner wrote: > On Dec 23, 2008, at 9:14 AM, Jon Harrop wrote: >> I discovered that LLVM's malloc only allows a 32-bit size argument, >> so you >> cannot use it to allocate huge blocks on 64-bit machines. So I >> considered >> replacing all of my uses of LLVM's malloc instruction with calls to >> the libc >> malloc function instead.

On Monday 07 December 2009 17:55:44 Chris Lattner wrote: > On Dec 7, 2009, at 9:49 AM, Garrison Venn wrote: > > So I gather this means that malloc was removed from the IR because > > there are platforms that don't have non-stack allocation semantics? > > No, it was removed because it wasn't necessary, and the malloc > 'instruction' didn't support 64-bit

On Thursday 26 February 2009 17:25:56 Chris Lattner wrote: > In my ideal world, this would be: > > 1. Subsystems [with clean interfaces] for thread management, > finalization, object model interactions, etc. > 2. Within different high-level designs (e.g. copying, mark/sweep, etc) > there can be replaceable policy components etc. > 3. A couple of actual GC implementations built

Having implemented a GC for HLVM, I am now turning my attention to implementing a GC that supports parallelism. To do this, I would like to use atomic instructions as well as mutexes. What is the status of LLVM's atomic instrinsics (e.g. CAS)? Is anyone using them in real projects? I realised that an obvious test would be to compile some simple example programs with llvm-g++ instead of

Hi, Using Squid with libc's malloc, I'm seeing a big difference between what top reports as memory used for the squid process (SIZE) and what Squid's cache manager reports that Squid has allocated (total KB allocated in the memory utilization page). Squid is using around twice as much memory as expected, and seems to grow without bounds (I run out of memory every now and then).

On Dec 7, 2009, at 9:49 AM, Garrison Venn wrote: > So I gather this means that malloc was removed from the IR because > there are platforms that don't have non-stack allocation semantics? No, it was removed because it wasn't necessary, and the malloc 'instruction' didn't support 64-bit targets. -Chris > > Garrison > > On Dec 7, 2009, at 12:21, Chris

Hello, For a course project, I am required to write a compiler for some language of my choice, and this compiler has to be implemented in a functional language. I have chosen create a *JIT* compiler for C source, and to implement my compiler in OCaml using LLVM for the back-end. I have experience using LLVM in C++ (I wrote a MATLAB JIT compiler not long ago), however, I am a bit puzzled as to how

Le Mon, 28 Aug 2017 16:45:16 +0200 Reindl Harald via samba <samba at lists.samba.org> écrivait: > Am 28.08.2017 um 16:29 schrieb Rowland Penny via samba: > > These are your non-default lines: > > > > server signing = mandatory > > and i bet that one has the major performance impact > __________________________ > > quote from microsoft: >

On Dec 7, 2009, at 11:24 AM, Jon Harrop wrote: > On Monday 07 December 2009 17:55:44 Chris Lattner wrote: >> On Dec 7, 2009, at 9:49 AM, Garrison Venn wrote: >>> So I gather this means that malloc was removed from the IR because >>> there are platforms that don't have non-stack allocation semantics? >> >> No, it was removed because it wasn't

So I gather this means that malloc was removed from the IR because there are platforms that don't have non-stack allocation semantics? Garrison On Dec 7, 2009, at 12:21, Chris Lattner wrote: > > On Dec 7, 2009, at 8:45 AM, Garrison Venn wrote: > >> Ouch! Didn't see that. So at the risk of irritating those still in the process of baking 2.7, what is the sanction way of

On Tuesday 04 December 2007 19:12, Chris Lattner wrote: > As far as I know, the only thing that is not 64-bit clean are the malloc > and alloca instructions, both of which take a fixed 32-bit integer operand > instead of either a 32-bit or 64-bit one. This can be worked around in > various ways, but the best solution is to just fix it. Patches welcome. Thanks for the clarification.

On Sunday 25 November 2007 12:23, Gordon Henriksen wrote: > On 2007-11-24, at 21:58, Jon Harrop wrote: > > - Garbage collection tuned for functional programming > > http://llvm.org/docs/GarbageCollection.html > > I've been doing some interesting work on this front. Getting Lattner- > cycles to have it reviewed and integrated is probably the biggest > challenge; LLVM

On Tuesday 04 December 2007 15:26, Duncan Sands wrote: > Hi Jon, > > > I notice that, even though I'm on 64-bit, many indexes are required by > > LLVM to be 32-bit integers. This won't be too important for the next few > > years except, I think, for the case of indexing large mmapped files which > > could already require more than 32-bits. > > > >

On Feb 5, 2010, at 7:19 PM, Jon Harrop wrote: > On Friday 05 February 2010 23:35:15 Evan Cheng wrote: >> Does anyone actually using it? > > Yes, many LLVM-based projects rely upon TCO to work correctly. Ok, that's all I need to know. > >> I'd prefer to just remove it to clean up the implementation if no one has >> any objections. > > Are you

On Tuesday 16 February 2010 03:51:00 Jianzhou Zhao wrote: > Does anyone know if there is any realistic project using LLVM-OCaml > Bindings? I've written a VM in OCaml built upon LLVM using LLVM's OCaml bindings: http://www.ffconsultancy.com/ocaml/hlvm/ There are at least two other significant users of LLVM's OCaml bindings, AFAIK. > How is the performance? Performance

On Saturday 06 February 2010 02:42:47 Evan Cheng wrote: > On Feb 5, 2010, at 7:19 PM, Jon Harrop wrote: > > On Friday 05 February 2010 23:35:15 Evan Cheng wrote: > >> Does anyone actually using it? > > > > Yes, many LLVM-based projects rely upon TCO to work correctly. > > Ok, that's all I need to know. > > >> I'd prefer to just remove it to

In the C documentation on linux, malloc is defined to take a size parameter of type size_t. On my 64-bit linux machine, size_t turns out to be a 64-bit type. In LLVM, AllocationInst's require the array size passed to them to be a 32-bit type. Is there a reason that LLVM's intermediate representation restricts the array size to be a 32-bit type? Regards, Ryan

On Monday 04 January 2010 03:33:06 Simon Harris wrote: > On 04/01/2010, at 3:01 PM, Jon Harrop wrote: > > I am certainly interested in tail calls because my HLVM project relies > > upon LLVM's tail call elimination. However, I do not understand what tail > > calls LLVM is not currently eliminating that you plan to eliminate? > > Mutual recursion for a start: >

On Saturday 31 January 2009 03:42:04 Eli Friedman wrote: > On Fri, Jan 30, 2009 at 5:43 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > I just remembered an anomalous result that I stumbled upon whilst > > tweaking the command-line options to llvm-gcc. Specifically, the -msse3 > > flag > > The -msse3 flag? Does the -msse2 flag have a similar effect? Yes: $