Re: getting Core Haskell from GHC API with cross-module inlinings
On 6/17/10, Roman Beslik ber...@ukr.net wrote:
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Modules and their explicit export lists (are an annoyance)
Thanks everybody for your thoughts. Based on what I've read this is what I will do: - fork a 'foreign' library, if I need to extend it substantially - export everything explicitly - or set namespaces like this: - Library (with the more stable interface) - Library.Internal (which exports everything) Because of the rather good versioning system of Cabal (like library=x.y.z) this seems to be the most practical solution for me. Though it still would be nice if I could inject functions into other peoples' namespaces -- so to speak ;-) Gruss, Christian * Christian Höner zu Siederdissen choe...@tbi.univie.ac.at [19.06.2010 20:39]: Hi everybody, I'd like some input on other peoples' thoughts on this. Recently, I played around with a library that uses an explicit export list. While there are reasons for having one: - efficiencey (inlining in the module) - encapsulation in practice, it seems to me that they are more annoying than useful. For once, it would think that ghc should produce efficient good across modules with -O / -O2 anyway. But the more important thing is, that it makes extending module functionality a pain (eg. if a constructor is not exported using (..)). So, should I really fork a library just to be able to add a function? Btw. there are libraries, where an explicit export list is used, that export the right amount of information. For example, in 'vector' enough is exported to allow you to extend unboxed vectors. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users pgpQHU69ZqFzB.pgp Description: PGP signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Modules and their explicit export lists (are an annoyance)
Hi Christian, I encourage you to email the lists or the library maintainer before forking - ther might be ways to solve your problem in a different way or to get the functionality you On Jun 21, 2010 4:20 PM, Christian Höner zu Siederdissen choe...@tbi.univie.ac.at wrote: Thanks everybody for your thoughts. Based on what I've read this is what I will do: - fork a 'foreign' library, if I need to extend it substantially - export everything explicitly - or set namespaces like this: - Library (with the more stable interface) - Library.Internal (which exports everything) Because of the rather good versioning system of Cabal (like library=x.y.z) this seems to be the most practical solution for me. Though it still would be nice if I could inject functions into other peoples' namespaces -- so to speak ;-) Gruss, Christian * Christian Höner zu Siederdissen choe...@tbi.univie.ac.at [19.06.2010 20:39]: Hi everybody, I'd like some input on other peoples' thoughts on this. Recently, I played around with a library that uses an explicit export list. While there are reasons for havi... But the more important thing is, that it makes extending module functionality a pain (eg. if a c... Btw. there are libraries, where an explicit export list is used, that export the right amount of... Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/ma... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Modules and their explicit export lists (are an annoyance)
Aarg, the send button is way to toucy on my mail client. I was trying to say that you should contact the community or the package maintainer to try and work something out before forking. It is true that all of this is usually free software, but it is a lot easier to manage if there aren't a large number of packages out there of dubious status regarding how and why they are maintained. Are there any specific packages you're having trouble with at the moment? Thanks, Antoine On Jun 21, 2010 6:34 PM, Antoine Latter aslat...@gmail.com wrote: Hi Christian, I encourage you to email the lists or the library maintainer before forking - ther might be ways to solve your problem in a different way or to get the functionality you On Jun 21, 2010 4:20 PM, Christian Höner zu Siederdissen choe...@tbi.univie.ac.at wrote: ... played around with a library that uses an explicit export list. While there are reasons for havi... But the more important thing is, that it makes extending module functionality a pain (eg. if a c... Btw. there are libraries, where an explicit export list is used, that export the right amount of... Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/ma... ___ Glasgow-haskell-users mailing list Glasgo... ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: getting Core Haskell from GHC API with cross-module inlinings
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: getting Core Haskell from GHC API with cross-module inlinings
On 6/21/10, Roman Beslik ber...@ukr.net wrote: 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
