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:[email protected]]
> Sent: 18 March 2012 23:39
> To: Sergiu Ivanov
> Cc: Simon Marlow; Simon Marlow; [email protected]
> 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 <[email protected]> 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 :-(
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
