| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This actually caused a segfault in the optimized stage 2 compiler due to
wrong TBAA data.
Signed-off-by: David Terei <davidterei@gmail.com>
|
|
|
|
|
| |
Slightly more documentation, removed unused label map (huh),
removed MonadIO instance on LlvmM to improve encapsulation.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This combined patch reworks the LLVM backend in a number of ways:
1. Most prominently, we introduce a LlvmM monad carrying the contents of
the old LlvmEnv around. This patch completely removes LlvmEnv and
refactors towards standard library monad combinators wherever possible.
2. Support for streaming - we can now generate chunks of Llvm for Cmm as
it comes in. This might improve our speed.
3. To allow streaming, we need a more flexible way to handle forward
references. The solution (getGlobalPtr) unifies LlvmCodeGen.Data
and getHsFunc as well.
4. Skip alloca-allocation for registers that are actually never written.
LLVM will automatically eliminate these, but output is smaller and
friendlier to human eyes this way.
5. We use LlvmM to collect references for llvm.used. This allows places
other than cmmProcLlvmGens to generate entries.
|
|
|
|
|
|
| |
I am not quite sure at what point it makes sense to look at arrays as
pointers, but I ran into at least one use case that strongly suggested
doing it this way (calculating the actual size of structures, to be exact).
|
| |
|
|
|
|
|
| |
Also give them a proper constructor - getGlobalVar and getGlobalValue
map directly to the accessors.
|
|
|
|
|
|
|
| |
This patch reworks some parts of the LLVM pretty-printing code that were
still using Show and String. Now we should be using SDoc and Outputable
throughout. Note that many get*Name functions become pp*Name
here as a side-effect.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- MetaArgs is not needed, as variables are already meta data
- Same goes for MetaVal - its only reason for existing seems to be to
support LLVM's strange pretty-printing for meta-data annotations, and
I feel that is better to keep the data structure clean and handle it in
the pretty-printing instead.
- Rename "MetaData" to "MetaAnnot". Meta-data is still meta-data when it
is not associated with an expression or statement - for example compile
unit data for debugging. I feel the old name was a bit misleading.
- Make the renamed MetaAnnot a proper data type instead of a type alias
for a pair.
- Rename "MetaExpr" constructor to "MetaStruct". As the data is much more
like a LLVM structure (not array, as it can contain values).
- Fix a warning
|
|
|
|
| |
backend.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This patch adds support for LLVM vectors and vector operations to our internal
LLVM abstract syntax data types.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
In particular, this makes life simpler when we want to use a general
GHC SDoc in the middle of some LLVM.
|
| |
|
|
|
|
| |
Signed-off-by: David Terei <davidterei@gmail.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Patch from Erik de Castro Lopo <erikd@mega-nerd.com>.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|