[LLVMdev] Promoting malloc to alloca

[Reid Kleckner]

On Tue, Jul 13, 2010 at 2:46 AM, Matt Giuca <matt.giuca at gmail.com> wrote:
> Good point. Is there any annotation which says LLVM can remove the
> call if the result is unused (i.e., there are no side-effects), but it
> can't combine two calls into one (i.e., the result might be different
> each time). That seems like what "readonly" is for, but I thought I'd
> check.
>
> In other words, is it safe to annotate malloc as "readonly"?

You can think of readonly as meaning "purely functional", which malloc
certainly isn't.

>> Doing this in general requires either that the free can't be found or that it really is right before the function exit, or else there might be a good reason the memory is on the heap. Then we have to make sure that we don't transform malloc calls inside loops (unless we also prove they're independent and Just Leaked).
>>
>> How large a block of memory are you willing to move from heap to stack? What if it's a variable, how hard should we work to try to determine its upper bound (we probably can't with any reasonable amount of effort). And what type is the alloca? We could take the 4 from malloc(i32 4) and create an alloca i8, 4 and let instcombine try to sort it out.
>>
>> Where should we look for malloc calls? Note that we only do stack to register transformation on alloca's in the first basic block if they're stacked together in a row as the very first instructions in the function.
>
> Thanks, a useful summary of the problems.
>
> It sounds like this analysis is best implemented in a higher-level
> compiler, before generating LLVM code.

If you are programming in C++ and using the C++ API, then it would
probably be best to implement a custom LLVM pass that does this
transformation.

However, I'm going to go out on a limb and guess that since you're
writing a compiler for a functional language, you're programming in a
functional language and generating text LLVM assembly files to feed to
llc.  In that case, then you're probably better off doing your own
escape analysis.  :)

Reid