Continuing to decouple DynFlags, see #20730 for project plan and status
Adds two modules:
Driver.Config.Cmm: module that defines initCmmConfig :: DynFlags -> CmmConfig
Cmm.Config: defines the data type CmmConfig
Refactors instances of DynFlags in the compiler/GHC/Cmm to use CmmConfig instead of DynFlags.
This MR does not change Cmm/Parser.y
My reasoning is that since parsers are necessarily external facing DynFlags is an acceptable input, but I do not know how this integrates with the rest of the compiler.
CmmConfig has a field cmmNCGPayload due to oneSRT in Cmm.Info.Build:-- | Build an SRT for a set of blocks
oneSRT
:: CmmConfig
-> LabelMap CLabel -- which blocks are static function entry points
-> [SomeLabel] -- blocks in this set
-> [CAFLabel] -- labels for those blocks
-> Bool -- True <=> this SRT is for a CAF
-> Set CAFLabel -- SRT for this set
-> Set CLabel -- Static data labels in this group
-> StateT ModuleSRTInfo UniqSM
( [CmmDeclSRTs] -- SRT objects we built
, [(Label, CLabel)] -- SRT fields for these blocks' itbls
, [(Label, [SRTEntry])] -- SRTs to attach to static functions
, Bool -- Whether the group has CAF references
)
oneSRT cfg staticFuns lbls caf_lbls isCAF cafs static_data = do
topSRT <- get
let
this_mod = thisModule topSRT
config = cmmNCGPayload cfg this_mod -- <---- used right here
profile = cmmProfile cfg
platform = profilePlatform profile
srtMap = moduleSRTMap topSRT
And in the initCmmConfig function this field is populated with a PAP:
initCmmConfig :: DynFlags -> CmmConfig
initCmmConfig dflags = CmmConfig
{ cmmPlatform = targetPlatform dflags
, cmmBackend = backend dflags
, cmmProfile = targetProfile dflags
, cmmPositionInd = positionIndependent dflags
, cmmOptControlFlow = gopt Opt_CmmControlFlow dflags
, cmmOptDoLinting = gopt Opt_DoCmmLinting dflags
, cmmOptElimCommonBlks = gopt Opt_CmmElimCommonBlocks dflags
, cmmOptSink = gopt Opt_CmmSink dflags
, cmmDebugLevel = debugLevel dflags
, cmmNCGPayload = initNCGConfig dflags -- <----- partially applied right here
}This is a design decision and I'm open to suggestions.
What I chose was to allow a pass through field that curries DynFlags for the native code generator. This design maintains the design goal of only having initPhase functions input DynFlags and then passdown information to subsequent phases via handshakes, but also allows CmmConfig to not know anything about the DynFlags required by the native code generator. I think these are both advantages of the approach
The disadvantages is that we are smuggling in DynFlags via a PAP, but only this time we do not have type information that this is occurring. Similarly, if some downstream code needed to change a field in the hidden DynFlags then it can no longer do that because the partially applied DynFlags is read only now.
Other approaches might be to hold NCGConfig itself, however I'm unsure how this would be possible since NCGConfig is parameterized by Module, hence the PAP. Or we might mirror all of NCGConfig in a new type, but then this breaks separation of concerns and couples CmmConfig to NCGConfig.