[GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O

[GHC]

#13604: ghci no longer loads dynamic .o files by default if they were built with -O
-------------------------------------+-------------------------------------
        Reporter:  George            |                Owner:  dfeuer
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.2.2
       Component:  Compiler          |              Version:  8.2.1-rc1
      Resolution:                    |             Keywords:
                                     |  RecompilationCheck
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D3514
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by dfeuer):

 === Some summary ===

 The essence of this ticket is explained quite well by Edward in
 comment:11. I don't think I agree with Edward about how the interpretation
 of `-fobject-code` should play into everything, but his essential points
 stand:

 1. We want to be able to run `ghc --make` and be sure that we get
 compilation products entirely equivalent to compiling from scratch.

 2. We want `ghci` (especially) to be able to load `-dynamic`-compiled
 modules even if those modules were compiled with slightly different
 options.

 The question of what "slightly different" means is really up to the user.

 === The solution ===

 Fortunately, it looks like this is probably not hard! Currently, we use
 `fingerprintDynFlags` to calculate a fingerprint of all the dflags that it
 believes can affect the compilation result and (in `addFingerprints`)
 record that fingerprint in the `ModIface`. When we are compiling with
 flags that don't match, we recompile the dependencies. What we want to do,
 I believe, is record not only the fingerprint but also information about
 some of the individual options.

 Some thoughts:

 1. A change in whether cost center profiling is enabled `gopt
 Opt_SccProfilingOn dflags` absolutely mandates recompilation. I believe we
 want users to be able to (selectively) ignore changes to

   - `-O`
   - `-fhpc`
   - `-fignore-asserts`
   - Automatic cost-center insertion (`-fprof-...`)

   I think we can do this by using one fingerprint for each of these
 options, or, even simpler, for each option and each module, either "This
 module and its dependencies use value X" or "At least one dependency uses
 a different value than this module".

 2. I believe we're currently somewhat too conservative about language
 flags in general. For example, I wouldn't expect enabling `-X` +
 `DataKinds`, `AllowAmbiguousTypes`, `ExplicitNamespaces`,
 `ConstraintKinds`, `MultiParamTypeClasses`, `FunctionalDependencies`,
 `FlexibleInstances`, `FlexibleContexts`, `UndecidableInstances`,
 `TupleSections`, `TypeSynonymInstances`, `StandaloneDeriving`,
 `DefaultSignatures`, `NullaryTypeClasses`, `EmptyCase`, `MultiWayIf`, or
 `ConstrainedClassMethods` to be able to change the result of compiling any
 module that was successfully compiled before. For these options, we're
 really only interested if one of them is ''turned off'' that was
 previously ''turned on''. For these, rather than a proper fingerprint, we
 want to record, for each option and each module, whether the module or at
 least one of its dependencies was compiled with that flag.

 3. We should consider fingerprinting the result of running the
 preprocessor(s) over the source. If the `-D`, `-U`, or `-I` options
 change, or an `#include`d file changes, we only need to recompile if the
 results of preprocessing have actually changed.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13604#comment:30>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler