| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The old llvm mangler was horrible! Very slow
due to bad design and code. New version is
linear complexity as it should be and far
lower coefficients. This fixes trac 4838.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
The regular structure type adds padding to conform to the platform ABI,
which causes problems with structures storing doubles under windows since
we don't conform to the platform ABI there. So we use packed structures
instead now that don't do any padding.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Patch from Erik de Castro Lopo <erikd@mega-nerd.com>.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
LLVM supports creating pointers in two ways, firstly through
pointer arithmetic (by casting between pointers and ints)
and secondly using the getelementptr instruction. The second way
is preferable as it gives LLVM more information to work with.
This patch changes a lot of pointer related code from the first
method to the getelementptr method.
|
|
|
|
|
|
|
|
| |
Instead of calling the C library for these Cmm functions
we use intrinsic functions provided by llvm. LLVM will
then either create a compile time constant if possible, or
use a cpu instruction or as a last resort call the C
library.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
At the moment this gives a very slight performance boost of around 1 - 2%.
Future changes to the generated code though so that pointers are kept as
pointers more often instead of being cast to integer types straight away
should hopefully improve the benefit this brings.
|
| |
|
|
|
|
|
|
|
|
| |
Before all the stg registers were simply a bit type or
floating point type but now they can be declared to have
a pointer type to one of these. This will allow various
optimisations in the future in llvm since the type is
more accurate.
|
|
|
|
|
|
| |
These allow annotations of the code produced by the backend
which should bring some perforamnce gains. At the moment
the attributes aren't being used though.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This involved removing the old constant handling mechanism
which was fairly hard to use. Now being constant or not is
simply a property of a global variable instead of a separate
type.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
We do this through a gnu as feature called subsections,
where you can put data/code into a numbered subsection
and those subsections will be joined together in descending
order by gas at compile time.
|
|
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.
|