Skip to content

Have GHCi use object code for UnboxedTuples modules #15454

Michael Sloan requested to merge mgsloan/ghc:wip/T15454 into master

See #15454 (closed) . The idea is to automatically enable -fobject-code for modules that use UnboxedTuples, along with all the modules they depend on. When looking into how to solve this, I was pleased to find that there was already highly similar logic for enabling code generation when -fno-code is specified but TemplateHaskell is used. So, this turned out to be quick to implement.

I have some other changes to GHC that I will upload soon which make it so that when used with this change, GHC itself can be loaded into the interpreter, only using object code for about 15 modules.

Things still left to do / consider:

  • Add to release notes.

  • Allow use of non-temporary object files? This could also be useful for -fno-code + TH. There are some relevant comments in the code:

    We don't want to create .o or .hi files unless we have been asked to by the user. But we need them, so we patch their locations in the ModSummary with temporary files.

    Elsewhere there is a TODO note about -fno-code + TH:

    • Offer a -no-codedir command line option, and write what were temporary object files there. This would speed up recompilation.

    What if instead manual specification of -odir and -hidir was interpreted as an opt-in to persistent object files? While less explicit than a -no-codedir option, seems like a fairly reasonable way to opt-in.

  • Should we attempt to have the output explain to the user why a particular choice of bytecode vs object code is being made? Specifically, I found I needed to add some trace output in order to minimize the number of object-code modules used in GHC. Perhaps this can be dealt with in a subsequent change. This change alone seems fine to me - there is already some precedent for automagic target determination with -fno-code + TH.

Pinging @bgamari due to #13101

Edited by Matthew Pickering

Merge request reports