similar to: [LLVMdev] Promoting malloc to alloca

We don't have any such optimization. Firstly, the pointer has to not make it into any function call at all, since any function might in turn call free(). Then we need to do escape analysis as you pointed out, but that's not difficult. We do similar analysis to determine pointer capture already. Matt Giuca wrote: > I have a compiler which generates a lot of malloc instructions for

OK thanks for the replies. Yes, I was planning to use a garbage collector. This is for a functional language, so there's no real way to determine when memory needs to be freed without one. > Firstly, the pointer has to not make it into any function call at all, since any function might in turn call free(). Then we need to do escape analysis as you pointed out, but that's not

Matt Giuca wrote: > OK thanks for the replies. > > Yes, I was planning to use a garbage collector. This is for a > functional language, so there's no real way to determine when memory > needs to be freed without one. > >> Firstly, the pointer has to not make it into any function call at all, since any function might in turn call free(). Then we need to do escape

Duncan Sands wrote: > Hi Nick, > >> The attribute you're looking for, "delete if result is unused" doesn't >> exist in LLVM. I've considered it in the past, but the truth is that >> most of the time I want to eliminate dead malloc's, they *do* have a >> use: the matching free. At some point I expect I'm going to teach LLVM >> to

Hi Nick, > The attribute you're looking for, "delete if result is unused" doesn't > exist in LLVM. I've considered it in the past, but the truth is that > most of the time I want to eliminate dead malloc's, they *do* have a > use: the matching free. At some point I expect I'm going to teach LLVM > to remove dead malloc+free / new+delete /

Hi Nick, >>> The attribute you're looking for, "delete if result is unused" doesn't >>> exist in LLVM. I've considered it in the past, but the truth is that >>> most of the time I want to eliminate dead malloc's, they *do* have a >>> use: the matching free. At some point I expect I'm going to teach LLVM >>> to remove dead

I would like to profile heap usage on a per thread basis in a large application process. To do this I am tracking calls to malloc and free with the attached script. Everything seems to look OK with some simple test programmes, however, when I track the live system, the results suggest that one thread has grown by approximately 1Gb and I would be surprised if this was true because I ran pmap -x on

If <NumElements> is zero, what is the behavior of malloc() and alloca()? Can I call free() using the pointer that malloc() returns? Also, I'm assuming that free()ing a null pointer is a legal NOP? Regards, Jon

On Oct 6, 2007, at 9:14 AM, Jon Sargeant wrote: > If <NumElements> is zero, what is the behavior of malloc() and > alloca()? > Can I call free() using the pointer that malloc() returns? alloca is not standard. The behavior of malloc is covered in 7.20.3p1: If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or

Dale Johannesen wrote: > On Oct 6, 2007, at 9:14 AM, Jon Sargeant wrote: > >> If <NumElements> is zero, what is the behavior of malloc() and >> alloca()? >> Can I call free() using the pointer that malloc() returns? > > alloca is not standard. > The behavior of malloc is covered in 7.20.3p1: > > If the size of the space requested is zero, the

According to the LLVM manual, for both malloc and alloca: "If a constant alignment is specified, the value result of the allocation is guaranteed to be aligned to at least that boundary. If not specified, or if zero, the target can choose to align the allocation on any convenient boundary." I don't see the rationale for the second sentence, because it means that alloca and malloc

>what is a non-public state that no-one but you can access? (I’d call that private). malloc and free could both use global variables that are defined in libc, but are inaccessible to the program under compilation. >if you’re attribute is saying they have some internal state, then malloc() cannot access the state of free() and vice versa. Which is why it would be preferable to call it

>there would be two disjoint global states In some sense yes, but technically not disjoint. Functions marked with this attribute should still be able to access the globals within the program under compilation, if its not marked with ReadNone. >If malloc and free can both use global variables (there is no notion of library in the compiler) Inaccessible state here refers to any global that is

>is this "internal state” supposed to be private to the function? It could be private or not. Hence the name "inaccessible", to mean that the program under compilation has no access to the state. So while printf and malloc (for example) could share state in libc, the program under compilation cannot access this state. >how this flag would prevent the last “optimization”

On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: > > Is that > > assumption violated if I explicitly cast away const and pass the result > > to a function with NoAlias argument? > > Not immediately, no. It means that you can't access the constant > pointer's pointee directly within the noalias argument's scope. Access > to that object must go

Reid Spencer wrote: > On Wed, 2007-02-14 at 18:54 +0100, Nicola Lugato wrote: > >>I've made some other test and it looks like it don't remove even >>simple malloc/free couple. Maybe there's something wrong in the way i >>use the opt command. > > No, there's not. LLVM doesn't provide the transform you want. As Chris > mentioned, if you open a

>What if you had bitcode versions of your C library Then the definitions for these functions would be available. Would we still set function attributes to these functions in FunctionAttrs.cpp if their definitions were available? >This also seems a bit tailored to malloc/free, and can't work for user-defined allocation functions I don't think so. For example, printf would have the

On Wed, Dec 12, 2012 at 1:26 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > On Wed, Dec 12, 2012 at 11:01:01AM -0800, Dan Gohman wrote: >> > Is that >> > assumption violated if I explicitly cast away const and pass the result >> > to a function with NoAlias argument? >> >> Not immediately, no. It means that you can't access the

On Mon, 2003-06-16 at 17:33, John Criswell wrote: > What would be better yet is to modify the code so that it does not use > alloca() at all. There seems to be little reason to use it aside from > convenience (but perhaps I have missed something). I think the idea is that alloca can give (probably significant) performance gains when used properly. In the cases where you need

> > > It seems to me that there are two ways of thinking about this: either the > value of a pointer in IR is richer than its bit sequence, in which case > replacing p1 with p0 in a block predicated by p0 == p1 is an incorrect > transformation if you cannot prove that one pointer was based on the other, > Which would be a non-starter just from the cost of doing so, not to