LLVM optimisation passes / tables next to code

[Sergiu Ivanov]

Hello,

Looks like I'm back online :-)

There's still plenty of time before any of GSoC deadlines,
fortunately.  In fact, according to the official timeline
(http://bit.ly/zw1Gle), organisations aren't even allowed to submit
their own applications yet.

On Fri, Feb 10, 2012 at 12:34 AM, David Terei <davidterei at gmail.com> wrote:
>
> Welcome to the wonderful and painful world of GHC hacking :)

Thank you, I hope it's going to be painfully wonderful :-)

> If GHC decides to accept you and for the project you propose then
> I'd probably be the mentor. I think this is a good project to get
> done but also a risky one. We've had mixed SoC results and have
> progressively tried to put students onto more defined and straight
> forward tasks.

Hm, I see.  I can only appreciate of the convergence of task
formulations to something more concrete.

> The hacking would also be nearly 100% C++ as its the LLVM code base
> you need to change not GHC's so much.

Yes, that's what I would guess; but I feel too curious about the
project :-) I once had extensive experience with C++; I'm not that
up-to-date now, but there shouldn't be any trouble with that.

> If you're keen on this though I'd suggest you do the following to get
> some traction to show you could handle this as a project:
>
> 1. Read this bug ticket:
> http://hackage.haskell.org/trac/ghc/ticket/4213, I've put a short
> explanation of how I'd tackle this task.
>
> 2. Talk to the LLVM developers (please CC me on the emails). They will
> know if the method I propose are good or not and how keen they are to
> accept patches.

To gain at least some basic perspective over the situation I read:
http://llvm.org/docs/LangRef.html and
llvm.org/pubs/2010-09-HASKELLSYM-LLVM-GHC.pdf , the latter being your
article entitled "An LLVM Backend for GHC".  Your article proved very
helpful in that it effectively lifted me up from zero-level knowledge.

Before I actually tell the LLVM folk anything, I'd like to double
check my understanding of the matters by producing a summary of what I
have in my head.

GHC uses TNTC to reduce the invocation of a closure to a single
pointer lookup.  LLVM does not explicitly offer any control over how
the data and text sections are arranged.  The point of the project is
to make LLVM handle this in a way or another.

You have suggested two solutions:

1. Implement another special LLVM variable, llvm.order, which would
   list global variables and function names in the other they should
   appear in the object code.

2. Make it possible to explicitly attach a variable to a function, so
   that it eventually gets right before the code of the function.

Am I getting the things correctly?

Also, do you maybe know if this
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev is the right list to
ask the question?

> Basically your SoC application should include a clear description of
> how you'll implement the features needed in LLVM and indication that
> the LLVM developers are likely to accept such patches.

That's clear, thank you.  I hope we will be able to gain acceptance in
the LLVM team.

Sergiu