[LLVMdev] The best way to cope with AllocationInst type in old code?

[Frits van Bommel]

On Wed, Dec 15, 2010 at 5:32 PM, John Criswell <criswell at illinois.edu> wrote:
> As a related aside, I've been thinking for awhile that it would be nice
> to have an allocator analysis group.  Each pass in the analysis group
> would recognize the allocators for a particular language or system and
> be able to return useful information for a call to that allocator (e.g.,
> given a call to an allocator function, return an LLVM value representing
> the size of the allocation).  The passes could chain like alias analysis
> passes; if one pass doesn't recognize a call instruction as a call to an
> allocator, it can ask another pass if it can identify the call.

I like that idea.
Some thoughts:

1) It would also be useful to be able to find deallocations.
In particular, it'd be nice to be able to detect things like matching
'free(malloc(N))' or 'delete (new T)' pairs so we can delete them
after other uses have been optimized out.
Alternatively, if there uses left but we can prove that the memory
will be deleted before exiting the function (or that the pointer
doesn't escape the function[1]), turn the allocation into an alloca
instead.
Note that for GC allocators, turning an allocation into an alloca may
require some way to insert a destructor call matching an allocation
since it won't be explicitly present in the IR already.
1a) This might also allow deleting of undefined behavior like
mismatched allocation/deallocation, e.g. delete malloc(), free(new T),
delete new T[10], delete[] new string, etc. if we can figure out that
they *are* mismatched.

[1]: This is particularly useful for GC allocators, but not unique to
them: IIRC unused mallocs are already deleted by one of the current
passes.


2) How (or whether) to handle things like realloc() which might both
allocate *and* deallocate?
(Or a GC variant of this which allocates & copies if needed but leaves
the old allocation around for the GC)