| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Update Haddock submodule
Metric Increase:
haddock.compiler
|
| |
|
|
|
|
|
| |
Update Haddock submodule
Metric Increase:
haddock.compiler
|
| |
|
|
|
|
| |
incomplete-uni-patterns and incomplete-record-updates will be in -Wall at a
future date, so prepare for that by disabling those warnings on files that
trigger them.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This switches the compiler/ component to get compiled with
-XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
modules.
This is motivated by the upcoming "Prelude" re-export of
`Semigroup((<>))` which would cause lots of name clashes in every
modulewhich imports also `Outputable`
Reviewers: austin, goldfire, bgamari, alanz, simonmar
Reviewed By: bgamari
Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
Differential Revision: https://phabricator.haskell.org/D3989
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fundamental problem with `type UniqSet = UniqFM` is that `UniqSet`
has a key invariant `UniqFM` does not. For example, `fmap` over
`UniqSet` will generally produce nonsense.
* Upgrade `UniqSet` from a type synonym to a newtype.
* Remove unused and shady `extendVarSet_C` and `addOneToUniqSet_C`.
* Use cached unique in `tyConsOfType` by replacing
`unitNameEnv (tyConName tc) tc` with `unitUniqSet tc`.
Reviewers: austin, hvr, goldfire, simonmar, niteria, bgamari
Reviewed By: niteria
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D3146
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Bit-for-bit reproducible binaries are not a goal for now,
so this is just marking places that could be a problem.
Doing this will allow eltsUFM to be removed and will
leave only nonDetEltsUFM.
GHC Trac: #4012
|
| |
|
|
|
|
|
| |
This documents nondeterminism in code generation and removes
the nondeterministic ufmToList function. In the future someone
will have to use nonDetEltsUFM (with proper explanation)
or pprUFM.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I planned to just say that we don't care about this part.
Turns out I was able to document away the uses in the codegenerator.
Test Plan: ./validate
Reviewers: simonmar, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2307
GHC Trac Issues: #4012
|
| | |
|
| |
|
|
| |
-fwarn-redundant-constraints
|
| | |
|
| | |
|
| |
|
|
|
| |
We only use it for "compiler" sources, i.e. not for libraries.
Many modules have a -fno-warn-tabs kludge for now.
|
| |
|
|
|
|
|
| |
Renamed adjustUFM in GraphOps to adjustUFM_C, to account
for alternate argument order.
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* The old Reg type is now split into VirtualReg and RealReg.
* For the graph coloring allocator, the type of the register graph
is now (Graph VirtualReg RegClass RealReg), which shows that it colors
in nodes representing virtual regs with colors representing real regs.
(as was intended)
* RealReg contains two contructors, RealRegSingle and RealRegPair,
where RealRegPair is used to represent a SPARC double reg
constructed from two single precision FP regs.
* On SPARC we can now allocate double regs into an arbitrary register
pair, instead of reserving some reg ranges to only hold float/double values.
|
| |
|
|
|
|
| |
The x86 code generator sometimes generates nop moves like
movl %vI_a %vI_a, but we'll just ignore them for coalescing
purposes instead of emitting an error. It shouldn't hurt anything.
|
| | |
|
| |
|
|
|
| |
If these modules use UniqFM then we get a stack overflow when compiling
modules that use fundeps. I haven't tracked down the actual cause.
|
| |
|
|
|
| |
If these modules use UniqFM then we get a stack overflow when compiling
modules that use fundeps. I haven't tracked down the actual cause.
|
| |
|
|
| |
Fixes building with -Werror (i.e. validate) and GHC < 6.6
|
| |
|
|
|
|
|
|
|
|
|
| |
If iterative coalescing isn't turned on, then do a single aggressive
coalescing pass for the first build/color cycle and then back off to
conservative coalescing for subseqent passes.
Aggressive coalescing is a cheap way to eliminate lots of the reg-reg
moves, but it can make the graph less colorable - if we turn it on
for every pass then allocation for code with a large amount of register
pressure (ie SHA1) doesn't converge in a sensible number of cycles.
|
| |
|
|
|
|
| |
Coalescences must be applied to the unsimplified graph in the same order
they were found by the iterative coalescing algorithm - otherwise
the vreg rewrite mapping will be wrong and badness will ensue.
|
| |
|
|
|
|
|
|
| |
When -dasm-lint is turned on the register conflict graph is checked for
internal consistency after each build/color pass. Make sure that all
edges point to valid nodes, that nodes are colored differently to their
neighbours, and if the graph is supposed to be colored, that all nodes
actually have a color.
|
|
|
It is needed by cmm/StackColor, and hence is needed even when there is no
native code generator.
|
