getting Core Haskell from GHC API with cross-module inlinings
Hi. The following code compiles "A.hs" with GHC API: {{{ import GHC import Outputable import DynFlags ( defaultDynFlags ) libdir = "/usr/lib/ghc-6.12.1" targetFile = "A.hs" main = defaultErrorHandler defaultDynFlags $ do runGhc (Just libdir) $ do dflags <- fmap (\dflags -> dflags {optLevel = 2}) getSessionDynFlags setSessionDynFlags dflags c <- compileToCoreSimplified targetFile print (showSDoc (ppr c)) }}} A.hs: {{{ import Data.Maybe main = print (show (maybe False (\_ -> True) (Just False))) }}} When "A.hs" is compiled with GHC API, output contains a reference to 'maybe'. When "A.hs" is compiled with "ghc -O2 -ddump-simpl", 'maybe' is inlined and simplified. Why do outputs differ? -- Best regards, Roman Beslik.
On 6/17/10, Roman Beslik
Hi. The following code compiles "A.hs" with GHC API: {{{ import GHC import Outputable import DynFlags ( defaultDynFlags ) libdir = "/usr/lib/ghc-6.12.1" targetFile = "A.hs" main = defaultErrorHandler defaultDynFlags $ do runGhc (Just libdir) $ do dflags <- fmap (\dflags -> dflags {optLevel = 2}) getSessionDynFlags
Hi, Roman -- The problem you're seeing, where insufficient optimization occurs, is in the above line. If I replace it with: dflags <- fmap (updOptLevel 2) getSessionDynFlags then I get a result where "maybe" has been inlined away. The reason is that the optimization sequence is controlled by several different fields within DynFlags, and just changing the optLevel field doesn't update the other fields. The updOptLevel function (defined in DynFlags, so you'll have to import that module explicitly) does. Also, I don't know what you're trying to do, but I recommend looking at GHC's External Core feature: http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ext-core.html and at the extcore and linkcore libraries: http://hackage.haskell.org/package/extcore http://hackage.haskell.org/package/linkcore IMO, it's easier than using the API to generate Core. If you find any problems with External Core or the packages above, let me know (I'm the maintainer). Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "I knew I'd hate Cobol the moment I saw they'd used 'perform' instead of 'do'." -- Larry Wall
On 21.06.10 21:45, Tim Chevalier wrote:
Also, I don't know what you're trying to do, but I recommend looking at GHC's External Core feature: http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ext-core.html and at the extcore and linkcore libraries: http://hackage.haskell.org/package/extcore http://hackage.haskell.org/package/linkcore
Thanks, Tim. I will look into it. I'm trying to: - get source code on different stages of processing in GHC; - dig to the GHC function which is responsible for some alteration in a source code. It is hard to trace a link between source code appearing as values in GHC functions and what "-ddump-simpl" outputs. And I guess that "-ddump-simpl" provides too coarse control of source code processing. So I try to call GHC functions directly. It is important that source code processing in GHC and libraries you mentioned (and the "ghc" library) should be identical. -- Best regards, Roman Beslik.
On 6/21/10, Roman Beslik
I'm trying to: - get source code on different stages of processing in GHC;
Probably not hard to do by giving different combinations of compiler flags -- you could do this with either the API or External Core.
- dig to the GHC function which is responsible for some alteration in a source code.
That would be harder. It would require modifying GHC quite a bit, but I could imagine getting there by using Core's "Note" construct and then getting the results as External Core.
It is hard to trace a link between source code appearing as values in GHC functions and what "-ddump-simpl" outputs. And I guess that "-ddump-simpl"
Indeed, I think that including enough information in an External Core file, or internal Core module, to map any value back to the original Haskell expression would be a research project in and of itself. Part of that project would involve specifying exactly what "the original Haskell expression" means -- for example, in the presence of aggressive inlining... Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "In a land of quince jelly, apple butter, apricot jam, blueberry preserves, pear conserves, and lemon marmalade, you always get grape jelly." -- William Least Heat-Moon
On 22.06.10 05:01, Tim Chevalier wrote:
It is hard to trace a link between source code appearing as values in GHC functions and what "-ddump-simpl" outputs. And I guess that "-ddump-simpl"
Indeed, I think that including enough information in an External Core file, or internal Core module, to map any value back to the original Haskell expression would be a research project in and of itself. Part of that project would involve specifying exactly what "the original Haskell expression" means -- for example, in the presence of aggressive inlining...
That is too big. For now I simply cut a small problematic part of a program. There are only values I want to see in it. -- Best regards, Roman Beslik.
participants (2)
-
Roman Beslik -
Tim Chevalier