GHCi recompilation avoidance UI
Simon Peyton Jones
simonpj at microsoft.com
Wed Nov 1 08:46:20 UTC 2017
I'm lost.
* What causes the undesired behaviour in GHC 8.2.1?
Is it this?
- GHCi wants to load module B with flags F
- There is a B.o but the flags differ
- So GHCi recompiles B to bytecode
* How does (1) help?
* Does (2) propose a new command (:load *M vs :load M)?
If so, how does it help.
* Is (3), what is the spec of the proposed new flags?
Is it this?
- GHC wants to compile module B with flags F
- There is a B.o compiled with flags F'
- And B.hs (and its dependencies) have not changed
- Then normally we'd recompile F unless F = F'
- But with -fignore-optim-changes we would weaken that equality to
ignore differences between F and F' that only affected optimisation
level (the list of such flags would need to be written out)
- And similarly for -fignore-hpc-changes
Precision is all!
Thanks
Simon
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of David
| Feuer
| Sent: 31 October 2017 15:42
| To: ghc-devs at haskell.org
| Subject: GHCi recompilation avoidance UI
|
| Changes in GHC 8.2.1 lead to a lot of recompilation, because GHCi now
| refuses to load optimized code unless -fobject-code (and optimization
| flags) are enabled. I propose the following slight modification to
| https://ghc.haskell.org/trac/ghc/ticket/13604#comment:48
|
| 1. Optimization flags (except -O0) imply -fobject-code. This ensures
| that GHC respects optimization flags regardless of --interactive.
|
| 2. Even when -fobject-code is on, :load *M will load M as bytecode.
| This provides the "escape hatch" from -fobject-code that you need to
| use debugging features, etc.
|
| 3. New -fignore-optim-changes and -fignore-hpc-changes (Phab:D4123)
| flags should enable users to put together object code and bytecode with
| diverse optimization levels/options and HPC options while still
| updating automatically based on source changes and whether profiling is
| enabled.
|
| Does this seem like a reasonable way forward?
|
| David Feuer
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.ha
| skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
| devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cd533ac396d6a4a6ff68208d52
| 076040e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636450613629249637
| &sdata=9duvpS1xcNXXUm%2BOJgWg4jFBCgvT3SqPJMU2k8Rdxj0%3D&reserved=0
More information about the ghc-devs
mailing list