On Wed, Nov 1, 2017 at 1:46 AM, Simon Peyton Jones via ghc-devs wrote:

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?

From my perspective, what happened is that GHC 8.2 started including the -O and -fhpc flags in the hash for recompilation avoidance, so it's started to notice when those particular flags differ. However, ghci has always rejected those two flags, courtesy of DynFlags.makeDynFlagsConsistent. The result is that it's now impossible for ghci to load modules compiled with those flags, since it will never have the right flags. The reason that's a problem is that it's really convenient to run tests (compiled with -fhpc) interactively, and use the GHC API to interpret code when the rest of the system is compiled with -O. That latter usage might be on thin ice according to the comment on makeDynFlagsConsistent, but in practice it's worked fine for a long time.

I'll let David answer about how #1 helps, but it looks like maybe ghci could have supported -O just fine with -fobject-code, so it should have been using that to determine whether or not to reject -O, not --interactive.

* Does (2) propose a new command (:load *M vs :load M)? If so, how does it help.

:load *M has always been present, so I'm not sure what is the difference. Maybe it didn't override -fobject-code before. I'll let David answer this and #3. But I think the effect of the flags in #3 would be "go back to <8.2", which is to say, omit -O and -fhpc from the interface hash. So yes, I think your description sounds right.

I started digging back into this today, particularly considering Simon PJ's view that it's a bit odd for optimization flags to imply -fobject-code (specifically because we could potentially support optimization for the bytecode interpreter some day). I'm left even more lost about exactly what we want. I believe it's fairly clear that, as Simon M wrote,

[W]e'll want at least -fignore-optim-changes to be the default, so that GHCi does the expected thing when you have compiled object files.

Based on Simon PJ's comment, I believe we want to *continue* to discard optimization flags when -fobject-code is not enabled. As for my suggestion in (2), I spent the last couple hours attempting to figure out what would be necessary to allow :load *M to load a module interpreted even when using -fobject-code, but found myself utterly lost in the module loading logic. I see that the IIModule constructor is deeply involved in this, but I haven't been able to figure out where/how that interacts with -fobject-code to determine whether the module will actually be loaded interpreted or compiled. Can someone give me a clue? On Thursday, November 2, 2017 10:21:07 AM EST Simon Marlow wrote:

On 31 October 2017 at 15:42, David Feuer wrote:

...

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.

Yes, I think this is probably what we want. I'm not sure how smooth it will be to implement though.

...

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.

As I mentioned on the diff, I think we'll want at least -fignore-optim-changes to be the default, so that GHCi does the expected thing when you have compiled object files.

Cheers Simon

David, Perhaps it would be good to defer changing the behaviour of :load *M (I believe you that it's hard, that code is quite convoluted) and for now just focus on making GHCi able to load compiled object code again, which I think is a much simpler problem? Cheers Simon On 21 November 2017 at 21:49, David Feuer wrote:

I started digging back into this today, particularly considering Simon PJ's view that it's a bit odd for optimization flags to imply -fobject-code (specifically because we could potentially support optimization for the bytecode interpreter some day). I'm left even more lost about exactly what we want. I believe it's fairly clear that, as Simon M wrote,

...

[W]e'll want at least -fignore-optim-changes to be the default, so that GHCi does the expected thing when you have compiled object files.

Based on Simon PJ's comment, I believe we want to *continue* to discard optimization flags when -fobject-code is not enabled. As for my suggestion in (2), I spent the last couple hours attempting to figure out what would be necessary to allow :load *M to load a module interpreted even when using -fobject-code, but found myself utterly lost in the module loading logic. I see that the IIModule constructor is deeply involved in this, but I haven't been able to figure out where/how that interacts with -fobject-code to determine whether the module will actually be loaded interpreted or compiled. Can someone give me a clue?

...

On 31 October 2017 at 15:42, David Feuer wrote:

...

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

...

...

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

On Thursday, November 2, 2017 10:21:07 AM EST Simon Marlow wrote: propose 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.

Yes, I think this is probably what we want. I'm not sure how smooth it will be to implement though.

...

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.

As I mentioned on the diff, I think we'll want at least -fignore-optim-changes to be the default, so that GHCi does the expected thing when you have compiled object files.

Cheers Simon