| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the past the canonical way for constructing an SDoc string literal was the
composition `ptext . sLit`. But for some time now we have function `text` that
does the same. Plus it has some rules that optimize its runtime behaviour.
This patch takes all uses of `ptext . sLit` in the compiler and replaces them
with calls to `text`. The main benefits of this patch are clener (shorter) code
and less dependencies between module, because many modules now do not need to
import `FastString`. I don't expect any performance benefits - we mostly use
SDocs to report errors and it seems there is little to be gained here.
Test Plan: ./validate
Reviewers: bgamari, austin, goldfire, hvr, alanz
Subscribers: goldfire, thomie, mpickering
Differential Revision: https://phabricator.haskell.org/D1784
|
| |
|
|
|
| |
George's new exhaustiveness checker now realizes these are impossible.
Yay!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Introduced in 6c7b41cc2b24f533697a62bf1843507ae043fc97.
I checked the rest of that commit, and this is all that was left to revert.
Test Plan: x
Reviewers: ezyang, austin
Reviewed By: ezyang, austin
Subscribers: simonmar, ezyang, carter, thomie
Differential Revision: https://phabricator.haskell.org/D241
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In this example we ended up with some code that was only reachable via
an info table, because a branch had been optimised away by the native
code generator. The register allocator then got confused because it
was only considering the first block of the proc to be an entry point,
when actually any of the info tables are entry points.
Test Plan: validate
Reviewers: simonpj, austin
Subscribers: simonmar, relrod, carter
Differential Revision: https://phabricator.haskell.org/D88
|
| |
|
|
|
|
|
| |
A previous fix to this was wrong: f5879acd018494b84233f26fba828ce376d0f81d
and left some unreachable code behind. So rather than try to be clever and
do this at the same time as the strongly-connected-component analysis, I'm
doing a separate reachability pass first.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
reorganized, while following the convention, to
- place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
any `{-# OPTIONS_GHC #-}`-lines.
- Moreover, if the list of language extensions fit into a single
`{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
individual language extension. In both cases, try to keep the
enumeration alphabetically ordered.
(The latter layout is preferable as it's more diff-friendly)
While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
|
| |
|
|
|
|
|
| |
This checks that all the required extensions are enabled for the
inferred type signature.
Updates binary and vector submodules.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem with unreachable code is that it might refer to undefined
registers. This happens accidentally: a block can be orphaned by an
optimisation, for example when the result of a comparsion becomes
known.
The register allocator panics when it finds an undefined register,
because they shouldn't occur in generated code. So we need to also
discard unreachable code to prevent this panic being triggered by
optimisations.
The register alloator already does a strongly-connected component
analysis, so it ought to be easy to make it discard unreachable code
as part of that traversal. It turns out that we need a different
variant of the scc algorithm to do that (see Digraph), however the new
variant also generates slightly better code by putting the blocks
within a loop in a better order for register allocation.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This removes the OldCmm data type and the CmmCvt pass that converts
new Cmm to OldCmm. The backends (NCGs, LLVM and C) have all been
converted to consume new Cmm.
The main difference between the two data types is that conditional
branches in new Cmm have both true/false successors, whereas in OldCmm
the false case was a fallthrough. To generate slightly better code we
occasionally need to invert a conditional to ensure that the
branch-not-taken becomes a fallthrough; this was previously done in
CmmCvt, and it is now done in CmmContFlowOpt.
We could go further and use the Hoopl Block representation for native
code, which would mean that we could use Hoopl's postorderDfs and
analyses for native code, but for now I've left it as is, using the
old ListGraph representation for native code.
|
| |
|
|
|
|
|
| |
All Cmm procedures now include the set of global registers that are live on
procedure entry, i.e., the global registers used to pass arguments to the
procedure. Only global registers that are use to pass arguments are included in
this list.
|
| |\ |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Proc-point splitting is only required by backends that do not support
having proc-points within a code block (that is, everything except the
native backend, i.e. LLVM and C).
Not doing proc-point splitting saves some compilation time, and might
produce slightly better code in some cases.
|
| | |
|
| | |
|
| |
|
|
|
| |
We can now get the Platform from the DynFlags inside an SDoc, so we
no longer need to pass the Platform in.
|
| | |
|
| |
|
|
| |
And some knock-on changes
|
| |
|
|
|
| |
CmmTop -> CmmDecl
CmmPgm -> CmmGroup
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There's now a variant of the Outputable class that knows what
platform we're targetting:
class PlatformOutputable a where
pprPlatform :: Platform -> a -> SDoc
pprPlatformPrec :: Platform -> Rational -> a -> SDoc
and various instances have had to be converted to use that class,
and we pass Platform around accordingly.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
I introduced this to support explicitly recording the info table label
in RawCmm for another patch I am working on, but it turned out to lead
to significant simplification in those parts of the compiler that
consume RawCmm.
Now, instead of lots of tests for null [CmmStatic] we have a simple
test of a Maybe, and have reduced the number of guys that need to know
how to convert entry->info labels by a TON. There are only 3 callers
of that function now!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I observed that the [CmmStatics] within CmmData uses the list in a very stylised way.
The first item in the list is almost invariably a CmmDataLabel. Many parts of the
compiler pattern match on this list and fail if this is not true.
This patch makes the invariant explicit by introducing a structured type CmmStatics
that holds the label and the list of remaining [CmmStatic].
There is one wrinkle: the x86 backend sometimes wants to output an alignment directive just
before the label. However, this can be easily fixed up by parameterising the native codegen
over the type of CmmStatics (though the GenCmmTop parameterisation) and using a pair
(Alignment, CmmStatics) there instead.
As a result, I think we will be able to remove CmmAlign and CmmDataLabel from the CmmStatic
data type, thus nuking a lot of code and failing pattern matches. This change will come as part
of my next patch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the new code generator to make use of the Hoopl package
for dataflow analysis. Hoopl is a new boot package, and is maintained
in a separate upstream git repository (as usual, GHC has its own
lagging darcs mirror in http://darcs.haskell.org/packages/hoopl).
During this merge I squashed recent history into one patch. I tried
to rebase, but the history had some internal conflicts of its own
which made rebase extremely confusing, so I gave up. The history I
squashed was:
- Update new codegen to work with latest Hoopl
- Add some notes on new code gen to cmm-notes
- Enable Hoopl lag package.
- Add SPJ note to cmm-notes
- Improve GC calls on new code generator.
Work in this branch was done by:
- Milan Straka <fox@ucw.cz>
- John Dias <dias@cs.tufts.edu>
- David Terei <davidterei@gmail.com>
Edward Z. Yang <ezyang@mit.edu> merged in further changes from GHC HEAD
and fixed a few bugs.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This major patch implements the new OutsideIn constraint solving
algorithm in the typecheker, following our JFP paper "Modular type
inference with local assumptions".
Done with major help from Dimitrios Vytiniotis and Brent Yorgey.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
computeLiveness requires the SCCs of blocks to be in reverse dependent
order, and if they're not it was silently giving bad liveness info,
yielding a bad allocation.
Now it complains, loudly.
|
| |
|
|
| |
stg_split_marker)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* I've pushed the SPILL and RELOAD instrs down into the
LiveInstr type to make them easier to work with.
* When the graph allocator does a spill cycle it now just
re-annotates the LiveCmmTops instead of converting them
to NatCmmTops and back.
* This saves working out the SCCS again, and avoids rewriting
the SPILL and RELOAD meta instructions into real machine
instructions.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- nativeGen/Instruction defines a type class for a generic
instruction set. Each of the instruction sets we have,
X86, PPC and SPARC are instances of it.
- The register alloctors use this type class when they need
info about a certain register or instruction, such as
regUsage, mkSpillInstr, mkJumpInstr, patchRegs..
- nativeGen/Platform defines some data types enumerating
the architectures and operating systems supported by the
native code generator.
- DynFlags now keeps track of the current build platform, and
the PositionIndependentCode module uses this to decide what
to do instead of relying of #ifdefs.
- It's not totally retargetable yet. Some info info about the
build target is still hardwired, but I've tried to contain
most of it to a single module, TargetRegs.
- Moved the SPILL and RELOAD instructions into LiveInstr.
- Reg and RegClass now have their own modules, and are shared
across all architectures.
|
| |
|
