[LLVMdev] Dataflow analysis based optimisations

David Given dg at cowlark.com
Tue Aug 31 04:10:39 PDT 2010

On 29/08/10 16:28, Kenneth Uildriks wrote:
> Now the case where function A calls function B, and function B needs
> to return a pointer to a freshly-allocated object, is fairly common.
> One way to attack this is to have each function create its own
> "region" or "memory pool" and destroy it when it returns.
> This
> scheme will allow any call depth to be handled without a GC heap
> allocation, as long as no pointer to the object is ever stored in a
> global or heap object or passed through a capturing function
> parameter.

If I've understood you correctly, this still requires a run-time memory
allocation from the appropriate memory pool --- so I still get the
overhead of running a heap, although I do still get some optimisation
due to being able to explicitly free the pool rather than relying on the
garbage collector to do it.

I think all I need is the simple case where I lower calls to malloc to
alloca instructions if the result is only ever passed to nocapture
functions and is not returned. The function-that-returns-a-pointer case
(which my language does a lot) may be trivially manageable by relying on
said functions being inlined; I've yet to get LLVM to inline anything
yet, so I don't know how well this will work in practice.

> Is this project open-source?

It will be once I get it into a fit state to release...

┌─── dg@cowlark.com ───── http://www.cowlark.com ─────
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100831/4600b7d3/attachment.sig>

More information about the llvm-dev mailing list