GHCi recompilation avoidance UI

[Simon Marlow]

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 <david at 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 <david at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20171122/109f044e/attachment-0001.html>