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 <da...@well-typed.com> 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 Thursday, November 2, 2017 10:21:07 AM EST Simon Marlow wrote: > > On 31 October 2017 at 15:42, David Feuer <da...@well-typed.com> 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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs