Skip to content
GitLab
Projects
Groups
Snippets
/
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Sign in / Register
Toggle navigation
Menu
Open sidebar
Glasgow Haskell Compiler
GHC
Commits
3c9dc06b
Commit
3c9dc06b
authored
Dec 19, 2019
by
Brian Wignall
Committed by
Marge Bot
Jan 04, 2020
Browse files
Fix typos, via a Levenshtein-style corrector
parent
b2e0323f
Pipeline
#14214
failed with stages
in 378 minutes and 51 seconds
Changes
168
Pipelines
1
Hide whitespace changes
Inline
Side-by-side
compiler/GHC/Hs/Expr.hs
View file @
3c9dc06b
...
...
@@ -2572,7 +2572,7 @@ data ArithSeqInfo id
|
FromThenTo
(
LHsExpr
id
)
(
LHsExpr
id
)
(
LHsExpr
id
)
-- AZ: Sould ArithSeqInfo have a TTG extension?
-- AZ: S
h
ould ArithSeqInfo have a TTG extension?
instance
OutputableBndrId
p
=>
Outputable
(
ArithSeqInfo
(
GhcPass
p
))
where
...
...
compiler/GHC/Hs/Pat.hs
View file @
3c9dc06b
...
...
@@ -686,7 +686,7 @@ isIrrefutableHsPat :: (OutputableBndrId p) => LPat (GhcPass p) -> Bool
-- Specifically on a ConPatIn, which is what it sees for a
-- (LPat Name) in the renamer, it doesn't know the size of the
-- constructor family, so it returns False. Result: only
-- tuple patterns are considered irrefuable at the renamer stage.
-- tuple patterns are considered irrefu
t
able at the renamer stage.
--
-- But if it returns True, the pattern is definitely irrefutable
isIrrefutableHsPat
...
...
compiler/GHC/Platform/Regs.hs
View file @
3c9dc06b
...
...
@@ -42,7 +42,7 @@ callerSaves platform
-- The order matters (for the llvm backend anyway)! We must make sure to
-- maintain the order here with the order used in the LLVM calling conventions.
-- Note that also, this isn't all registers, just the ones that are currently
-- poss
b
ily mapped to real registers.
-- possi
b
ly mapped to real registers.
activeStgRegs
::
Platform
->
[
GlobalReg
]
activeStgRegs
platform
|
platformUnregisterised
platform
=
NoRegs
.
activeStgRegs
...
...
compiler/GHC/StgToCmm/Bind.hs
View file @
3c9dc06b
...
...
@@ -198,7 +198,7 @@ cgRhs :: Id
CgIdInfo
-- The info for this binding
,
FCode
CmmAGraph
-- A computation which will generate the
-- code for the binding, and return an
-- assignent of the form "x = Hp - n"
-- assign
m
ent of the form "x = Hp - n"
-- (see above)
)
...
...
compiler/GHC/StgToCmm/ExtCode.hs
View file @
3c9dc06b
...
...
@@ -102,7 +102,7 @@ instance HasDynFlags CmmParse where
return
(
d
,
dflags
))
-- | Takes the variable decarations and imports from the monad
-- | Takes the variable dec
l
arations and imports from the monad
-- and makes an environment, which is looped back into the computation.
-- In this way, we can have embedded declarations that scope over the whole
-- procedure, and imports that scope over the entire module.
...
...
compiler/GHC/StgToCmm/Prim.hs
View file @
3c9dc06b
...
...
@@ -2159,7 +2159,7 @@ vecElemProjectCast _ _ _ = Nothing
-- values!
-- The current design with respect to register mapping of scalars could
-- very well be the best,but exploring the design space and doing careful
-- measurments is the only only way to validate that.
-- measur
e
ments is the only only way to validate that.
-- In some next generation CPU ISAs, notably RISC V, the SIMD extension
-- includes support for a sort of run time CPU dependent vectorization parameter,
-- where a loop may act upon a single scalar each iteration OR some 2,4,8 ...
...
...
compiler/basicTypes/OccName.hs
View file @
3c9dc06b
...
...
@@ -582,7 +582,7 @@ mk_deriv occ_sp sys_prefix str =
mkOccNameFS
occ_sp
(
concatFS
$
sys_prefix
:
str
)
isDerivedOccName
::
OccName
->
Bool
-- ^ Test for definitions internally generated by GHC. This predicte
-- ^ Test for definitions internally generated by GHC. This predic
a
te
-- is used to suppress printing of internal definitions in some debug prints
isDerivedOccName
occ
=
case
occNameString
occ
of
...
...
compiler/basicTypes/VarSet.hs
View file @
3c9dc06b
...
...
@@ -319,7 +319,7 @@ seqDVarSet s = sizeDVarSet s `seq` ()
extendDVarSetList
::
DVarSet
->
[
Var
]
->
DVarSet
extendDVarSetList
=
addListToUniqDSet
-- | Convert a DVarSet to a VarSet by forgeting the order of insertion
-- | Convert a DVarSet to a VarSet by forget
t
ing the order of insertion
dVarSetToVarSet
::
DVarSet
->
VarSet
dVarSetToVarSet
=
unsafeUFMToUniqSet
.
udfmToUfm
.
getUniqDSet
...
...
compiler/cmm/CmmBuildInfoTables.hs
View file @
3c9dc06b
...
...
@@ -227,7 +227,7 @@ implemented.
case, if the closure is not locally defined then we can't point to
it directly from the info table, because this is the text section
which cannot contain runtime relocations. In this case we skip this
optimisation and generate the singleton SRT, becase SRTs are in the
optimisation and generate the singleton SRT, beca
u
se SRTs are in the
data section and *can* have relocatable references.
2. [FUN] A static function closure can also be an SRT, we simply put
...
...
compiler/cmm/CmmMachOp.hs
View file @
3c9dc06b
...
...
@@ -135,7 +135,7 @@ data MachOp
|
MO_VU_Quot
Length
Width
|
MO_VU_Rem
Length
Width
-- Floting point vector element insertion and extraction operations
-- Flo
a
ting point vector element insertion and extraction operations
|
MO_VF_Insert
Length
Width
-- Insert scalar into vector
|
MO_VF_Extract
Length
Width
-- Extract scalar from vector
...
...
compiler/cmm/CmmNode.hs
View file @
3c9dc06b
...
...
@@ -715,7 +715,7 @@ isTickSubScope = cmp
cmp
(
SubScope
u
s
)
s'
@
(
SubScope
u'
_
)
=
u
==
u'
||
cmp
s
s'
-- | Combine two tick scopes. The new scope should be sub-scope of
-- both parameters. We simplfy automatically if one tick scope is a
-- both parameters. We simpl
i
fy automatically if one tick scope is a
-- sub-scope of the other already.
combineTickScopes
::
CmmTickScope
->
CmmTickScope
->
CmmTickScope
combineTickScopes
s1
s2
...
...
compiler/cmm/CmmPipeline.hs
View file @
3c9dc06b
...
...
@@ -297,7 +297,7 @@ cpsTop hsc_env proc =
-- Sp = Sp + 16
-- ...y...y...
--
-- But since we don't see any benefits from running sinking bef
r
oe stack
-- But since we don't see any benefits from running sinking befo
r
e stack
-- layout, this situation probably doesn't arise too often in practice.
--
...
...
compiler/cmm/SMRep.hs
View file @
3c9dc06b
...
...
@@ -15,7 +15,7 @@ module SMRep (
StgHalfWord
,
fromStgHalfWord
,
toStgHalfWord
,
halfWordSize
,
halfWordSizeInBits
,
-- * Closure repesentation
-- * Closure rep
r
esentation
SMRep
(
..
),
-- CmmInfo sees the rep; no one else does
IsStatic
,
ClosureTypeInfo
(
..
),
ArgDescr
(
..
),
Liveness
,
...
...
compiler/cmm/cmm-notes
View file @
3c9dc06b
More notes (Aug 11)
~~~~~~~~~~~~~~~~~~
* CmmInfo.cmmToRawCmm expands info tables to their representations
(needed for .cmm files as well as the code generators)
* Why is FCode a lazy monad? That makes it inefficient.
We want laziness to get code out one procedure at a time,
but not at the instruction level.
UPDATE (31/5/2016): FCode is strict since 09afcc9b.
Things we did
* Remove CmmCvt.graphToZgraph (Conversion from old to new Cmm reps)
* Remove HscMain.optionallyConvertAndOrCPS (converted old Cmm to
new, ran pipeline, and converted back)
* Remove CmmDecl. Put its types in Cmm. Import Cmm into OldCmm
so it can get those types.
More notes (June 11)
~~~~~~~~~~~~~~~~~~~~
* In CmmContFlowOpts.branchChainElim, can a single block be the
successor of two calls?
* Check in ClosureInfo:
-- NB: Results here should line up with the results of SMRep.rtsClosureType
More notes (May 11)
~~~~~~~~~~~~~~~~~~~
In CmmNode, consider spliting CmmCall into two: call and jump
Notes on new codegen (Aug 10)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Things to do:
- Proc points pass all arguments on the stack, adding more code and
slowing down things a lot. We either need to fix this or even better
would be to get rid of proc points.
- Sort out Label, LabelMap, LabelSet versus BlockId, BlockEnv, BlockSet
dichotomy. Mostly this means global replace, but we also need to make
Label an instance of Outputable (probably in the Outputable module).
EZY: We should use Label, since that's the terminology Hoopl uses.
- AsmCodeGen has a generic Cmm optimiser; move this into new pipeline
EZY (2011-04-16): The mini-inliner has been generalized and ported,
but the constant folding and other optimizations need to still be
ported.
- AsmCodeGen has post-native-cg branch eliminator (shortCutBranches);
we ultimately want to share this with the Cmm branch eliminator.
- At the moment, references to global registers like Hp are "lowered"
late (in CgUtils.fixStgRegisters). We should do this early, in the
new native codegen, much in the way that we lower calling conventions.
Might need to be a bit sophisticated about aliasing.
- Move to new Cmm rep:
* Make native CG consume New Cmm;
* Convert Old Cmm->New Cmm to keep old path alive
* Produce New Cmm when reading in .cmm files
- Top-level SRT threading is a bit ugly
- See "CAFs" below; we want to totally refactor the way SRTs are calculated
- Garbage-collect https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/cps
moving good stuff into
https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/new-code-gen-pipeline
- Currently AsmCodeGen top level calls AsmCodeGen.cmmToCmm, which is a small
C-- optimiser. It has quite a lot of boilerplate folding code in AsmCodeGen
(cmmBlockConFold, cmmStmtConFold, cmmExprConFold), before calling out to
CmmOpt. ToDo: see what optimisations are being done; and do them before
AsmCodeGen.
- If we stick CAF and stack liveness info on a LastCall node (not LastRet/Jump)
then all CAF and stack liveness stuff be completed before we split
into separate C procedures.
Short term:
compute and attach liveness into LastCall
right at end, split, cvt to old rep
[must split before cvt, because old rep is not expressive enough]
Longer term:
when old rep disappears,
move the whole splitting game into the C back end *only*
(guided by the procpoint set)
----------------------------------------------------
Proc-points
----------------------------------------------------
Consider this program, which has a diamond control flow,
with a call on one branch
fn(p,x) {
h()
if b then { ... f(x) ...; q=5; goto J }
else { ...; q=7; goto J }
J: ..p...q...
}
then the join point J is a "proc-point". So, is 'p' passed to J
as a parameter? Or, if 'p' was saved on the stack anyway, perhaps
to keep it alive across the call to h(), maybe 'p' gets communicated
to J that way. This is an awkward choice. (We think that we currently
never pass variables to join points via arguments.)
Furthermore, there is *no way* to pass q to J in a register (other
than a parameter register).
What we want is to do register allocation across the whole caboodle.
Then we could drop all the code that deals with the above awkward
decisions about spilling variables across proc-points.
Note that J doesn't need an info table.
What we really want is for each LastCall (not LastJump/Ret)
to have an info table. Note that ProcPoints that are not successors
of calls don't need an info table.
Figuring out proc-points
~~~~~~~~~~~~~~~~~~~~~~~~
Proc-points are identified by
CmmProcPoint.minimalProcPointSet/extendPPSet Although there isn't
that much code, JD thinks that it could be done much more nicely using
a dominator analysis, using the Dataflow Engine.
----------------------------------------------------
CAFs
----------------------------------------------------
* The code for a procedure f may refer to either the *closure*
or the *entry point* of another top-level procedure g.
If f is live, then so is g. f's SRT must include g's closure.
* The CLabel for the entry-point/closure reveals whether g is
a CAF (or refers to CAFs). See the IdLabel constructor of CLabel.
* The CAF-ness of the original top-level definitions is figured out
(by TidyPgm) before we generate C--. This CafInfo is only set for
top-level Ids; nested bindings stay with MayHaveCafRefs.
* Currently an SRT contains (only) pointers to (top-level) closures.
* Consider this Core code
f = \x -> let g = \y -> ...x...y...h1...
in ...h2...g...
and suppose that h1, h2 have IdInfo of MayHaveCafRefs.
Therefore, so will f, But g will not (since it's nested).
This generates C-- roughly like this:
f_closure: .word f_entry
f_entry() [info-tbl-for-f] { ...jump g_entry...jump h2... }
g_entry() [info-tbl-for-g] { ...jump h1... }
Note that there is no top-level closure for g (only an info table).
This fact (whether or not there is a top-level closure) is recorded
in the InfoTable attached to the CmmProc for f, g
INVARIANT:
Any out-of-Group references to an IdLabel goes to
a Proc whose InfoTable says "I have a top-level closure".
Equivalently:
A CmmProc whose InfoTable says "I do not have a top-level
closure" is referred to only from its own Group.
* So: info-tbl-for-f must have an SRT that keeps h1,h2 alive
info-tbl-for-g must have an SRT that keeps h1 (only) alive
But if we just look for the free CAF refs, we get:
f h2 (only)
g h1
So we need to do a transitive closure thing to flesh out
f's keep-alive refs to include h1.
* The SRT info is the C_SRT field of Cmm.ClosureTypeInfo in a
CmmInfoTable attached to each CmmProc. CmmPipeline.toTops actually does
the attaching, right at the end of the pipeline. The C_SRT part
gives offsets within a single, shared table of closure pointers.
* DECIDED: we can generate SRTs based on the final Cmm program
without knowledge of how it is generated.
More notes (Aug 11)
~~~~~~~~~~~~~~~~~~
* CmmInfo.cmmToRawCmm expands info tables to their representations
(needed for .cmm files as well as the code generators)
* Why is FCode a lazy monad? That makes it inefficient.
We want laziness to get code out one procedure at a time,
but not at the instruction level.
UPDATE (31/5/2016): FCode is strict since 09afcc9b.
Things we did
* Remove CmmCvt.graphToZgraph (Conversion from old to new Cmm reps)
* Remove HscMain.optionallyConvertAndOrCPS (converted old Cmm to
new, ran pipeline, and converted back)
* Remove CmmDecl. Put its types in Cmm. Import Cmm into OldCmm
so it can get those types.
More notes (June 11)
~~~~~~~~~~~~~~~~~~~~
* In CmmContFlowOpts.branchChainElim, can a single block be the
successor of two calls?
* Check in ClosureInfo:
-- NB: Results here should line up with the results of SMRep.rtsClosureType
More notes (May 11)
~~~~~~~~~~~~~~~~~~~
In CmmNode, consider split
t
ing CmmCall into two: call and jump
Notes on new codegen (Aug 10)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Things to do:
- Proc points pass all arguments on the stack, adding more code and
slowing down things a lot. We either need to fix this or even better
would be to get rid of proc points.
- Sort out Label, LabelMap, LabelSet versus BlockId, BlockEnv, BlockSet
dichotomy. Mostly this means global replace, but we also need to make
Label an instance of Outputable (probably in the Outputable module).
EZY: We should use Label, since that's the terminology Hoopl uses.
- AsmCodeGen has a generic Cmm optimiser; move this into new pipeline
EZY (2011-04-16): The mini-inliner has been generalized and ported,
but the constant folding and other optimizations need to still be
ported.
- AsmCodeGen has post-native-cg branch eliminator (shortCutBranches);
we ultimately want to share this with the Cmm branch eliminator.
- At the moment, references to global registers like Hp are "lowered"
late (in CgUtils.fixStgRegisters). We should do this early, in the
new native codegen, much in the way that we lower calling conventions.
Might need to be a bit sophisticated about aliasing.
- Move to new Cmm rep:
* Make native CG consume New Cmm;
* Convert Old Cmm->New Cmm to keep old path alive
* Produce New Cmm when reading in .cmm files
- Top-level SRT threading is a bit ugly
- See "CAFs" below; we want to totally refactor the way SRTs are calculated
- Garbage-collect https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/cps
moving good stuff into
https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/new-code-gen-pipeline
- Currently AsmCodeGen top level calls AsmCodeGen.cmmToCmm, which is a small
C-- optimiser. It has quite a lot of boilerplate folding code in AsmCodeGen
(cmmBlockConFold, cmmStmtConFold, cmmExprConFold), before calling out to
CmmOpt. ToDo: see what optimisations are being done; and do them before
AsmCodeGen.
- If we stick CAF and stack liveness info on a LastCall node (not LastRet/Jump)
then all CAF and stack liveness stuff be completed before we split
into separate C procedures.
Short term:
compute and attach liveness into LastCall
right at end, split, cvt to old rep
[must split before cvt, because old rep is not expressive enough]
Longer term:
when old rep disappears,
move the whole splitting game into the C back end *only*
(guided by the procpoint set)
----------------------------------------------------
Proc-points
----------------------------------------------------
Consider this program, which has a diamond control flow,
with a call on one branch
fn(p,x) {
h()
if b then { ... f(x) ...; q=5; goto J }
else { ...; q=7; goto J }
J: ..p...q...
}
then the join point J is a "proc-point". So, is 'p' passed to J
as a parameter? Or, if 'p' was saved on the stack anyway, perhaps
to keep it alive across the call to h(), maybe 'p' gets communicated
to J that way. This is an awkward choice. (We think that we currently
never pass variables to join points via arguments.)
Furthermore, there is *no way* to pass q to J in a register (other
than a parameter register).
What we want is to do register allocation across the whole caboodle.
Then we could drop all the code that deals with the above awkward
decisions about spilling variables across proc-points.
Note that J doesn't need an info table.
What we really want is for each LastCall (not LastJump/Ret)
to have an info table. Note that ProcPoints that are not successors
of calls don't need an info table.
Figuring out proc-points
~~~~~~~~~~~~~~~~~~~~~~~~
Proc-points are identified by
CmmProcPoint.minimalProcPointSet/extendPPSet Although there isn't
that much code, JD thinks that it could be done much more nicely using
a dominator analysis, using the Dataflow Engine.
----------------------------------------------------
CAFs
----------------------------------------------------
* The code for a procedure f may refer to either the *closure*
or the *entry point* of another top-level procedure g.
If f is live, then so is g. f's SRT must include g's closure.
* The CLabel for the entry-point/closure reveals whether g is
a CAF (or refers to CAFs). See the IdLabel constructor of CLabel.
* The CAF-ness of the original top-level definitions is figured out
(by TidyPgm) before we generate C--. This CafInfo is only set for
top-level Ids; nested bindings stay with MayHaveCafRefs.
* Currently an SRT contains (only) pointers to (top-level) closures.
* Consider this Core code
f = \x -> let g = \y -> ...x...y...h1...
in ...h2...g...
and suppose that h1, h2 have IdInfo of MayHaveCafRefs.
Therefore, so will f, But g will not (since it's nested).
This generates C-- roughly like this:
f_closure: .word f_entry
f_entry() [info-tbl-for-f] { ...jump g_entry...jump h2... }
g_entry() [info-tbl-for-g] { ...jump h1... }
Note that there is no top-level closure for g (only an info table).
This fact (whether or not there is a top-level closure) is recorded
in the InfoTable attached to the CmmProc for f, g
INVARIANT:
Any out-of-Group references to an IdLabel goes to
a Proc whose InfoTable says "I have a top-level closure".
Equivalently:
A CmmProc whose InfoTable says "I do not have a top-level
closure" is referred to only from its own Group.
* So: info-tbl-for-f must have an SRT that keeps h1,h2 alive
info-tbl-for-g must have an SRT that keeps h1 (only) alive
But if we just look for the free CAF refs, we get:
f h2 (only)
g h1
So we need to do a transitive closure thing to flesh out
f's keep-alive refs to include h1.
* The SRT info is the C_SRT field of Cmm.ClosureTypeInfo in a
CmmInfoTable attached to each CmmProc. CmmPipeline.toTops actually does
the attaching, right at the end of the pipeline. The C_SRT part
gives offsets within a single, shared table of closure pointers.
* DECIDED: we can generate SRTs based on the final Cmm program
without knowledge of how it is generated.
compiler/coreSyn/CoreFVs.hs
View file @
3c9dc06b
...
...
@@ -496,7 +496,7 @@ ruleLhsFreeIds = fvVarSet . ruleLhsFVIds
ruleLhsFreeIdsList
::
CoreRule
->
[
Var
]
-- ^ This finds all locally-defined free Ids on the left hand side of a rule
-- and returns them as a deterministically ordered list
ruleLhsFreeIdsList
=
fvVarList
.
ruleLhsFVIds
ruleLhsFVIds
::
CoreRule
->
FV
...
...
compiler/coreSyn/CoreLint.hs
View file @
3c9dc06b
...
...
@@ -166,7 +166,7 @@ That is, use a type let. See Note [Type let] in CoreSyn.
However, when linting <body> we need to remember that a=Int, else we might
reject a correct program. So we carry a type substitution (in this example
[a -> Int]) and apply this substitution before comparing types. The functin
[a -> Int]) and apply this substitution before comparing types. The functi
o
n
lintInTy :: Type -> LintM (Type, Kind)
returns a substituted type.
...
...
compiler/coreSyn/CoreSubst.hs
View file @
3c9dc06b
...
...
@@ -745,7 +745,7 @@ Breakpoints can't handle free variables with unlifted types anyway.
{-
Note [Worker inlining]
~~~~~~~~~~~~~~~~~~~~~~
A worker can get sustituted away entirely.
A worker can get su
b
stituted away entirely.
- it might be trivial
- it might simply be very small
We do not treat an InlWrapper as an 'occurrence' in the occurrence
...
...
compiler/coreSyn/CoreTidy.hs
View file @
3c9dc06b
...
...
@@ -196,7 +196,7 @@ tidyLetBndr rec_tidy_env env@(tidy_env, var_env) id
-- Don't attempt to recompute arity here; this is just tidying!
-- Trying to do so led to #17294
--
-- Set inline-prag info so that we preseve it across
-- Set inline-prag info so that we prese
r
ve it across
-- separate compilation boundaries
old_info
=
idInfo
id
new_info
=
vanillaIdInfo
...
...
compiler/coreSyn/MkCore.hs
View file @
3c9dc06b
...
...
@@ -886,7 +886,7 @@ After doing case-of-known-constructor, and expanding $WMkT we get
Yikes! That bogusly appears to evaluate the absentError!
This is extremely tiresome. Another way to think of this is that, in
Core, it is an invariant that a strict data contructor, like MkT, must
Core, it is an invariant that a strict data con
s
tructor, like MkT, must
be applied only to an argument in HNF. So (absentError "blah") had
better be non-bottom.
...
...
compiler/deSugar/DsListComp.hs
View file @
3c9dc06b
...
...
@@ -380,7 +380,7 @@ dfBindComp c_id n_id (pat, core_list1) quals = do
b
<-
newSysLocalDs
b_ty
x
<-
newSysLocalDs
x_ty
-- build rest of the comprehesion
-- build rest of the comprehe
n
sion
core_rest
<-
dfListComp
c_id
b
quals
-- build the pattern match
...
...
Prev
1
2
3
4
5
…
9
Next
Marge Bot
💬
@marge-bot
mentioned in merge request
!2331 (closed)
·
Jan 04, 2020
mentioned in merge request
!2331 (closed)
mentioned in merge request !2331
Toggle commit list
Write
Preview
Supports
Markdown
0%
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment