jhc vs ghc and the surprising result involving ghc generatedassembly.

[Simon Peyton-Jones]

All this interesting talk of back ends is somewhat topical at GHC
HQ....It may well be that we can share some technology here.

GHC uses C-- as its intermediate representation; 
	Core  ==>   C--    either==>   assembly code
			       or==>        C
 
Currently the Core->C-- step is done in one big go, by the code
generator.  The C-- code uses NO native C-- calls; instead, it uses tail
calls only, and builds a totally explicit stack as a data structure in
the heap.

But Chris Thompson-Walsh, as his undergrad project, is writing a CPS
converter for C--, so we can do this
	Core   ==>   C--    ==>   C-- with tail calls only
The first step is code generation, converting lambda code to C--, but
now this is C-- with native C-- calls.  The stack is implicit, entirely
under C--'s control.

The second step is the CPS conversion.   After the CPS conversion the
stack is totally explicit.

One reason for doing all this is that it factors the rather-complicated
code generator into two pieces. The second reason is that if we had a
full-blown C-- compiler available, supporting the full runtime
interface, we could print out the C-- before the CPS conversion, and use
the C-- compiler for the rest.


Anyway, apart from the first code-gen step, not much of this process is
particularly GHC specific.  At the moment it's entirely implemented in
Haskell.  One of the things Chris is going to look at (if he has time)
is packaging the Cmm data type, its various useful functions (e.g. data
flow analysis), and his CPS converter, as a Cabal package that GHC just
uses.  Then other people could use it too.

Furthermore the Cmm data type would be the perfect place to spot
self-tail calls, eliminate memory operations etc -- all the things that
John has been mentioning in his message.  That is, a C-- ==> C--
optimiser would be a nice independent project.

My reason for mentioning all this now, when it's still partly
vapourware, is to see if anyone else is interested.  In particular,
perhaps a C-- optimiser for jhc would be usable in GHC and vice versa.

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org
[mailto:glasgow-haskell-users-
| bounces at haskell.org] On Behalf Of John Meacham
| Sent: 27 October 2005 00:37
| To: glasgow-haskell-users at haskell.org
| Subject: Re: jhc vs ghc and the surprising result involving ghc
generatedassembly.
| 
| On Wed, Oct 26, 2005 at 12:24:14PM -0400, Jan-Willem Maessen wrote:
| > Nice analysis.  I indeed found with phc that shadow stack references
| > absolutely killed performance, and I aggressively cached stack
| > locations in locals, spilling to stack only when GC information
| > needed to be accurate.  [There was a giant infrastructure to save
| > only live data to stack, but we won't go into that now as it was the
| > source of almost all the codegen bugs...]
| 
| phc? there is another haskell compiler out there?
| 
| > This makes a big difference.  The phc compiler even put comments in
| > the code so that I could figure out what came from where.
| 
| yeah, that is something I would like to add. Unfortunatly I wasn't
| forward thinking enough to put annotation points everywhere I might
| eventually need them so I will have to go through and do that at some
| point :)
| 
| > I'm impressed that gcc found this.  It's definitely living a bit
| > dangerously, and your suggestions below for self tail call handling
| > are the ones I found most effective.  (They also allowed me to
bypass
| > some prologue garbage, since phc used a one-C-function-per-Haskell-
| > function model with internal resumption points.)  Non-self tail
calls
| > I was careful to compile to:
| >   return f(...);
| > I expect from the above that gcc does better at spotting tail calls
now.
| 
[..rest cut..]