David Feuer <da...@well-typed.com> writes:

> 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?
>
It seems to me like the place to start would be occurrences of the
targetAllowObjCode field of Target.

Cheers,

- Ben

Attachment: signature.asc
Description: PGP signature

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply via email to