external core

John Meacham john at repetae.net
Thu Jul 28 20:34:11 EDT 2005


On Thu, Jul 28, 2005 at 01:46:41PM +0200, Josef Svenningsson wrote:
> John, could you elaborate on suggestion of having a "pass-through core
> processor that interacts with ghc". I'm not quite sure I understand
> what you're after. But it sounds interesting :-)

Ideally, this is what I would like from ghc and a library (some of this
already exists).

ghc should have the options 

--input-core  - take hcr files as input and compile them as normal
--output-core - spit out hcr files instead of generating code

note that with these two, you have access to just ghc's optimizer by
using both of them. 

now the fun one is --passes 

--passes cpranalysis,ext=./myopt,strictness,ext=./myopt2,fullylazy

basically, this just defines the transformations ghc is to use. the
interesting new bit is 'ext=<program>' which is a program that simply
takes ghc core on stdin and spits out core on stdout. this allows easy
adding of custom passes to ghc. 

so, with all these features you can (easily, simply)

- write custom optimization passes 
- use just ghc's front end
- use just ghc's back end 
- play with the order of passes
- use ghc's optimizer as a plugin for a different compiler that speaks
  core


now out of the library:

module Core where

-- type defining core syntax, probably similar (but simpler) to the one in ghc
data Core = ....

-- parse core, in a monad for reporting errors
parseCore :: Monad m => String -> m Core
parseCore = ...

-- print core 
printCore :: Core -> String
printCore = ... 


this will allow you to write custom optimization passes  really easily:


main = getContents >>= putStr . printCore . customPass . parseCore

-- your optimization
customPass :: Core -> Core
customPass = ...


the functions would also be useful when using just ghc's front or back
end. 


        John




-- 
John Meacham - ⑆repetae.net⑆john⑈ 


More information about the Libraries mailing list