GHCi recompilation avoidance UI

[Simon Peyton Jones]

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