[LLVMdev] Dataflow analysis based optimisations

Kenneth Uildriks kennethuil at gmail.com
Fri Aug 27 18:20:54 PDT 2010


There are passes which mark function parameters as "nocapture", which
means that the function does not store the passed-in pointer for use
after that function returns.  If pointers to a newly created object
are only ever passed through "nocapture" parameters, never stored in a
global, and not returned from the function, then that object is dead
when the function that created the object returns.

There may be other possibilities for proving an object dead, but this
should definitely be safe.

On Fri, Aug 27, 2010 at 7:16 PM, David Given <dg at cowlark.com> wrote:
> I'm working on an LLVM-based compiler for a very closure-centric
> language. It's becoming apparent that it's going to suffer heavily from
> garbage collector churn, as all the useful programming idioms the
> language makes possible are going to involve memory allocations, either
> to create objects or to allocate storage for upvalues.
>
> However, it's possible to optimise away a lot of heap allocations, and
> replace them with allocas instead, *if* we know that the lifetime of the
> object is going to be shorter than the lifetime of the stack frame ---
> in other words, the object will be used strictly inside the function and
> nowhere else. This applies to both upvalues and objects.
>
> Does LLVM have any mechanism for doing the kind of dataflow analysis
> required to track object lifetime like this?
>
> --
> ┌─── dg@cowlark.com ───── http://www.cowlark.com ─────
>> │ "Home is where, when you have to go there, they have to take you in."
> │ --- Cordelia Naismith
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>




More information about the llvm-dev mailing list