LLVM optimisation passes / tables next to code

[Simon Marlow]

I've been thinking a little about this.  If some extension to LLVM is needed to support TNTC, then I think it might be better to go all the way and support arbitrary labels with info tables, not just top-level procedures.  Also, it has to be possible to take the address of a label.  Obviously, such labels cannot be optimised away, and there has to be enough information in the intermediate code to be able to construct control-flow graphs.

The reason to do this is that it will let us generate much better code from GHC.  In the absence of support for labels with info tables, the code generator has to do something called "proc point analysis" and split up procedures in order to guarantee that (a) only top-level procs have info tables, and (b) we never jump into the middle of a proc.  Every time we split up a proc, everything that is live in local variables has to be saved or passed to the other procedure explicitly, which adds overhead.  Furthermore, to generate code that doesn't do this a lot, the Stg-to-Cmm code generator has to be "proc-point aware" and avoid generating code that requires too many proc-point splits (I've been doing quite a lot of this in the new codegen recently).

Even simple loops will suffer from this: e.g. in the new code generator a recursive let-no-escape will compile directly into a loop, that is unless it contains a heap check or stack check or even just a call to another function - any of these will force the let-no-escape to be a proc point, forcing all its parameters to be explicitly saved/restored on every iteration.

We can make the NCG support arbitrary labels with info tables quite easily, and I'm very tempted to do it because it will let us generate much better code.  But the LLVM route will not be able to benefit, unless we can find a way to do this with LLVM too.

Cheers,
	Simon 

> -----Original Message-----
> From: David Terei [mailto:davidterei at gmail.com]
> Sent: 18 March 2012 23:39
> To: Sergiu Ivanov
> Cc: Simon Marlow; Simon Marlow; Cvs-ghc at haskell.org
> Subject: Re: LLVM optimisation passes / tables next to code
> 
> Sounds fine. However it may be best to start with the native code
> generator (NCG). It will also need to be changed to make sure the backends
> are all compatible. It probably is easier to work with to implement the
> proposed TNTC alternative. Can then test this alternative works and with
> good performance.
> 
> Cheers,
> David
> 
> On 17 March 2012 13:10, Sergiu Ivanov <unlimitedscolobb at gmail.com> wrote:
> > Hello,
> >
> > I've seen Chris Lattner of LLVM voice in the favour of adding blobs of
> > inline assembler at the start of functions, which sounds like good
> > news!
> >
> > I'll be now (quickly) reading http://llvm.org/docs/tutorial/ to get an
> > overall picture and I will also try to fix a bug to show that I'm
> > actually capable of coding.
> >
> > Does this plan sound good?
> >
> > Sergiu
> >
> > P.S. Unfortunately, my time is quite limited now, since the university
> > consumes quite a lot of my effort.  I beg my pardon for my
> > sluggishness in advance :-(