| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
assignTemp_ is intended to make sure that the expression gets assigned
to a temporary in case that's needed in order to avoid a register
getting trashed due to a function call.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 is already handled by the Cmm code generator so LLVM is simply
duplicating work. LLVM also doesn't know which ones are actually live
so saves them all which causes a fair performance overhead for C calls
on x64. We stop llvm saving them across the call by storing undef to
them just before the call.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was done as part of an honours thesis at UNSW, the paper describing the
work and results can be found at:
http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf
A Homepage for the backend can be found at:
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM
Quick summary of performance is that for the 'nofib' benchmark suite, runtimes
are within 5% slower than the NCG and generally better than the C code
generator. For some code though, such as the DPH projects benchmark, the LLVM
code generator outperforms the NCG and C code generator by about a 25%
reduction in run times.
|
| |
|
|
|
|
|
|
|
| |
Allow a temporary assignment to be pushed past an assignment to a
global if the global is not mentioned in the rhs of the assignment we
are inlining.
This fixes up some bad code. We should make sure we're doing
something equivalent in the new backend in due course.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The type of the CmmLabel ctor is now
CmmLabel :: PackageId -> FastString -> CmmLabelInfo -> CLabel
- When you construct a CmmLabel you have to explicitly say what
package it is in. Many of these will just use rtsPackageId, but
I've left it this way to remind people not to pretend labels are
in the RTS package when they're not.
- When parsing a Cmm file, labels that are not defined in the
current file are assumed to be in the RTS package.
Labels imported like
import label
are assumed to be in a generic "foreign" package, which is different
from the current one.
Labels imported like
import "package-name" label
are marked as coming from the named package.
This last one is needed for the integer-gmp library as we want to
refer to labels that are not in the same compilation unit, but
are in the same non-rts package.
This should help remove the nasty #ifdef __PIC__ stuff from
integer-gmp/cbits/gmp-wrappers.cmm
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The first phase of this tidyup is focussed on the header files, and in
particular making sure we are exposinng publicly exactly what we need
to, and no more.
- Rts.h now includes everything that the RTS exposes publicly,
rather than a random subset of it.
- Most of the public header files have moved into subdirectories, and
many of them have been renamed. But clients should not need to
include any of the other headers directly, just #include the main
public headers: Rts.h, HsFFI.h, RtsAPI.h.
- All the headers needed for via-C compilation have moved into the
stg subdirectory, which is self-contained. Most of the headers for
the rest of the RTS APIs have moved into the rts subdirectory.
- I left MachDeps.h where it is, because it is so widely used in
Haskell code.
- I left a deprecated stub for RtsFlags.h in place. The flag
structures are now exposed by Rts.h.
- Various internal APIs are no longer exposed by public header files.
- Various bits of dead code and declarations have been removed
- More gcc warnings are turned on, and the RTS code is more
warning-clean.
- More source files #include "PosixSource.h", and hence only use
standard POSIX (1003.1c-1995) interfaces.
There is a lot more tidying up still to do, this is just the first
pass. I also intend to standardise the names for external RTS APIs
(e.g use the rts_ prefix consistently), and declare the internal APIs
as hidden for shared libraries.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to generated things like:
extern StgWordArray (newCAF) __attribute__((aligned (8)));
((void (*)(void *))(W_)&newCAF)((void *)R1.w);
(which is to say, pretend that newCAF is some data, then cast it to a
function and call it).
This goes wrong on at least IA64, where:
A function pointer on the ia64 does not point to the first byte of
code. Intsead, it points to a structure that describes the function.
The first quadword in the structure is the address of the first byte
of code
so we end up dereferencing function pointers one time too many, and
segfaulting.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This merge does not turn on the new codegen (which only compiles
a select few programs at this point),
but it does introduce some changes to the old code generator.
The high bits:
1. The Rep Swamp patch is finally here.
The highlight is that the representation of types at the
machine level has changed.
Consequently, this patch contains updates across several back ends.
2. The new Stg -> Cmm path is here, although it appears to have a
fair number of bugs lurking.
3. Many improvements along the CmmCPSZ path, including:
o stack layout
o some code for infotables, half of which is right and half wrong
o proc-point splitting
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eager blackholing can improve parallel performance by reducing the
chances that two threads perform the same computation. However, it
has a cost: one extra memory write per thunk entry.
To get the best results, any code which may be executed in parallel
should be compiled with eager blackholing turned on. But since
there's a cost for sequential code, we make it optional and turn it on
for the parallel package only. It might be a good idea to compile
applications (or modules) with parallel code in with
-feager-blackholing.
ToDo: document -feager-blackholing.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
o Moved BlockId stuff to a new file to avoid module recursion
o Defined stack areas for parameter-passing locations and spill slots
o Part way through replacing copy in and copy out nodes
- added movement instructions for stack pointer
- added movement instructions for call and return parameters
(but not with the proper calling conventions)
o Inserting spills and reloads for proc points is now procpoint-aware
(it was relying on the presence of a CopyIn node as a proxy for
procpoint knowledge)
o Changed ZipDataflow to expect AGraphs (instead of being polymorphic in
the type of graph)
|
| |
|
|
|
|
| |
C-- no longer has 'hints'; to guide parameter passing, it
has 'kinds'. Renamed type constructor, data constructor, and record
fields accordingly
|
| | |
|
| |
|
|
|
|
|
| |
This allows the instance of UserOfLocalRegs to be within Haskell98, and IMHO
makes the code a little cleaner generally.
This is one small (though tedious) step towards making GHC's code more
portable...
|
| | |
|
| |
|
|
|
| |
This fixes building on NixOS. I'm not sure why it worked everywhere else,
but not on NixOS, before.
|
| |
|
|
| |
Fixes building with -Werror (i.e. validate) and GHC < 6.6
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've renamed a number of type and data constructors within Cmm so that
the names used in the compiler may more closely reflect the C--
specification 2.1. I've done a bit of other renaming as well.
Highlights:
CmmFormal and CmmActual now bear a CmmKind (which for now is a
MachHint as before)
CmmFormals = [CmmFormal] and CmmActuals = [CmmActual]
suitable changes have been made to both code and nonterminals in the
Cmm parser (which is as yet untested)
For reasons I don't understand, parts of the code generator use a
sequence of 'formal parameters' with no C-- kinds. For these we now
have the types
type CmmFormalWithoutKind = LocalReg
type CmmFormalsWithoutKinds = [CmmFormalWithoutKind]
A great many appearances of (Tau, MachHint) have been simplified to
the appropriate CmmFormal or CmmActual, though I'm sure there are
more opportunities.
Kind and its data constructors are now renamed to
data GCKind = GCKindPtr | GCKindNonPtr
to avoid confusion with the Kind used in the type checker and with CmmKind.
Finally, in a somewhat unrelated bit (and in honor of Simon PJ, who
thought of the name), the Whalley/Davidson 'transaction limit' is now
called 'OptimizationFuel' with the net effect that there are no longer
two unrelated uses of the abbreviation 'tx'.
|
| |
|
|
|
|
|
|
|
| |
The type parameter to a C-- procedure now represents a control-flow
graph, not a single instruction. The newtype ListGraph preserves the
current representation while enabling other representations and a
sensible way of prettyprinting. Except for a few changes in the
prettyprinter the new compiler binary should be bit-for-bit identical
to the old.
|
| | |
|
| |
|
|
|
|
|
| |
Older GHCs can't parse OPTIONS_GHC.
This also changes the URL referenced for the -w options from
WorkingConventions#Warnings to CodingStyle#Warnings for the compiler
modules.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This patch should have no effect; it's mainly comments, layout,
plus this contructor name change.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of attaching the information whether a Label is going to be
accessed dynamically or not (distinction between IdLabel/DynLabel and
additional flags in ModuleInitLabel and PlainModuleInitLabel), we hand
dflags through the CmmOpt monad and the NatM monad. Before calling
labelDynamic in PositionIndependentCode, we extract thisPackage from
dflags and supply the current package to labelDynamic, so it can take
this information into account instead of extracting it from the labels
itself. This simplifies a lot of code in codeGen that just hands
through this_pkg.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements pointer tagging as per our ICFP'07 paper "Faster
laziness using dynamic pointer tagging". It improves performance by
10-15% for most workloads, including GHC itself.
The original patches were by Alexey Rodriguez Yakushev
<mrchebas@gmail.com>, with additions and improvements by me. I've
re-recorded the development as a single patch.
The basic idea is this: we use the low 2 bits of a pointer to a heap
object (3 bits on a 64-bit architecture) to encode some information
about the object pointed to. For a constructor, we encode the "tag"
of the constructor (e.g. True vs. False), for a function closure its
arity. This enables some decisions to be made without dereferencing
the pointer, which speeds up some common operations. In particular it
enables us to avoid costly indirect jumps in many cases.
More information in the commentary:
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/PointerTagging
|
| | |
|
| |
|
|
|
| |
This is needed because CgForeign and parts of the CPS pass now use
'callerSaveVolatileRegs' and not all platforms have access to the NCG.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fairly complete implementation, however
two 'panic's have been placed in the critical path
where the implementation is still a bit lacking so
do not expect it to run quite yet.
One call to panic is because we still need to create
a GC block for procedures that don't have them yet.
(cmm/CmmCPS.hs:continuationToProc)
The other is due to the need to convert from a
ContinuationInfo to a CmmInfo.
(codeGen/CgInfoTbls.hs:emitClosureCodeAndInfoTable)
(codeGen/CgInfoTbls.hs:emitReturnTarget)
|
| | |
|
| |
|
|
|
|
| |
This version should compile but is still incomplete as it introduces
potential bugs at the places marked 'TODO FIXME NOW'.
It is being recorded to help keep track of changes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This frees the Cmm data type from keeping a list of live global registers
in CmmCall which helps prepare for the CPS conversion phase.
CPS conversion does its own liveness analysis and takes input that should
not directly refer to parameter registers (e.g. R1, F5, D3, L2). Since
these are the only things which could occur in the live global register
list, CPS conversion makes that field of the CmmCall constructor obsolite.
Once the CPS conversion pass is fully implemented, global register saving
will move from codeGen into the CPS pass. Until then, this patch
is worth scrutinizing and testing to ensure it doesn't cause any performance
or correctness problems as the code passed to the backends by the CPS
converting will look very similar to the code that this patch makes codeGen
pass to the backend.
|
| | |
|
| |
|
|
|
|
| |
In the generated code for case-of-variable, test the tag of the
scrutinee closure and only enter if it is unevaluated. Also turn
*off* vectored returns.
|
| |
|
|
|
|
| |
In the generated code for case-of-variable, test the tag of the
scrutinee closure and only enter if it is unevaluated. Also turn
*off* vectored returns.
|
| | |
|
| |
|
|
| |
Only affects -fasm: gcc makes its own decisions about jump tables
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch is a start on removing import lists and generally tidying
up the top of each module. In addition to removing import lists:
- Change DATA.IOREF -> Data.IORef etc.
- Change List -> Data.List etc.
- Remove $Id$
- Update copyrights
- Re-order imports to put non-GHC imports last
- Remove some unused and duplicate imports
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch pushes through one fundamental change: a module is now
identified by the pair of its package and module name, whereas
previously it was identified by its module name alone. This means
that now a program can contain multiple modules with the same name, as
long as they belong to different packages.
This is a language change - the Haskell report says nothing about
packages, but it is now necessary to understand packages in order to
understand GHC's module system. For example, a type T from module M
in package P is different from a type T from module M in package Q.
Previously this wasn't an issue because there could only be a single
module M in the program.
The "module restriction" on combining packages has therefore been
lifted, and a program can contain multiple versions of the same
package.
Note that none of the proposed syntax changes have yet been
implemented, but the architecture is geared towards supporting import
declarations qualified by package name, and that is probably the next
step.
It is now necessary to specify the package name when compiling a
package, using the -package-name flag (which has been un-deprecated).
Fortunately Cabal still uses -package-name.
Certain packages are "wired in". Currently the wired-in packages are:
base, haskell98, template-haskell and rts, and are always referred to
by these versionless names. Other packages are referred to with full
package IDs (eg. "network-1.0"). This is because the compiler needs
to refer to entities in the wired-in packages, and we didn't want to
bake the version of these packages into the comiler. It's conceivable
that someone might want to upgrade the base package independently of
GHC.
Internal changes:
- There are two module-related types:
ModuleName just a FastString, the name of a module
Module a pair of a PackageId and ModuleName
A mapping from ModuleName can be a UniqFM, but a mapping from Module
must be a FiniteMap (we provide it as ModuleEnv).
- The "HomeModules" type that was passed around the compiler is now
gone, replaced in most cases by the current package name which is
contained in DynFlags. We can tell whether a Module comes from the
current package by comparing its package name against the current
package.
- While I was here, I changed PrintUnqual to be a little more useful:
it now returns the ModuleName that the identifier should be qualified
with according to the current scope, rather than its original
module. Also, PrintUnqual tells whether to qualify module names with
package names (currently unused).
Docs to follow.
|
|
|
Most of the other users of the fptools build system have migrated to
Cabal, and with the move to darcs we can now flatten the source tree
without losing history, so here goes.
The main change is that the ghc/ subdir is gone, and most of what it
contained is now at the top level. The build system now makes no
pretense at being multi-project, it is just the GHC build system.
No doubt this will break many things, and there will be a period of
instability while we fix the dependencies. A straightforward build
should work, but I haven't yet fixed binary/source distributions.
Changes to the Building Guide will follow, too.
|
