| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
It's a bit confusing to have .gitignore files spread all over the
filesystem. This commit tries to consolidate those into one .gitignore
file per component. Moreover, we try to describe files to be ignored which
happen to have a common identifying pattern by glob patterns.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
I used this shell command to automatically generate the lists:
for i in `git ls-files -o --exclude-standard --directory`; do echo "`basename $i`" >> "`dirname "$i"`/.gitignore"; done
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
| |
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update several old
http://hackage.haskell.org/trac/ghc
URLs references to the current
http://ghc.haskell.org/trac/ghc
URLs.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These array types are smaller than Array# and MutableArray# and are
faster when the array size is small, as they don't have the overhead
of a card table. Having no card table reduces the closure size with 2
words in the typical small array case and leads to less work when
updating or GC:ing the array.
Reduces both the runtime and memory allocation by 8.8% on my insert
benchmark for the HashMap type in the unordered-containers package,
which makes use of lots of small arrays. With tuned GC settings
(i.e. `+RTS -A6M`) the runtime reduction is 15%.
Fixes #8923.
|
|
|
|
|
|
|
| |
This adds -fmax-inline-memcpy-insns and -fmax-inline-memset-insns.
These flags control when we inline calls to memcpy/memset with
statically known arguments. The flag naming style is taken from GCC
and the same limit is used by both GCC and LLVM.
|
|
|
|
| |
The fix was to ghc-prim.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The inline allocation version is 69% faster than the out-of-line
version, when cloning an array of 16 unit elements on a 64-bit
machine.
Comparing the new and the old primop implementations isn't
straightforward. The old version had a missing heap check that I
discovered during the development of the new version. Comparing the
old and the new version would requiring fixing the old version, which
in turn means reimplementing the equivalent of MAYBE_CG in StgCmmPrim.
The inline allocation threshold is configurable via
-fmax-inline-alloc-size which gives the maximum array size, in bytes,
to allocate inline. The size does not include the closure header size.
Allowing the same primop to be either inline or out-of-line has some
implication for how we lay out heap checks. We always place a heap
check around out-of-line primops, as they may allocate outside of our
knowledge. However, for the inline primops we only allow allocation
via the standard means (i.e. virtHp). Since the clone primops might be
either inline or out-of-line the heap check layout code now consults
shouldInlinePrimOp to know whether a primop will be inlined.
|
|
|
|
|
|
|
| |
This results in a 57% runtime decrease when allocating an array of 128
bytes on a 64-bit machine.
Fixes #8876.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Authored-by: Carter Tazio Schonwald <carter.schonwald@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
| |
Issue #8393
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes:
* Adding a test for bswap16 with a low byte >= 128
* Also test the byteSwapN functions from GHC.Word, tested both INLINE
and not INLINE, so we test both independent parts: the compilation of
base, and the backend compiling the code *using* base.
* Fix the usage of byteSwapN# primitives in the test, by masking off
* the higher bits when storing the results in Word16/Word32.
Thanks to Reid Barton for the investigation.
Authored-by: Reid Barton <rwbarton@gmail.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
|
|
| |
Essentially the same tests as for the existing ByteArray# ones.
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
|
|
|
| |
Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
|
|
|
|
|
|
| |
This test is a bit speculative, because I can't reproduce problem
on my machine. Still, it should work because it produces the same
Cmm that originally caused the problem.
|
|
|
|
|
| |
Authored-by: David Luposchainsky <dluposchainsky@gmail.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
| |
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
| |
|
|
|
|
| |
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
| |
Signed-off-by: Austin Seipp <aseipp@pobox.com>
|
|
|
|
|
|
| |
This reverts commit abbf27e7922cf15df4c74b502e51f4bc12923215.
(committed accidentally, the fix for that ticket isn't ready yet)
|
| |
|
|
|
|
| |
Something is wrong with byte-swapping!
|
| |
|
|
|
|
| |
Patch from Vincent Hanquez.
|
|
|
|
|
| |
It used to give different answers because of different
exceptoin behaviour (cf #7737) but now it's fine
|
|
|
|
| |
The driver now also supports nested lists of setup functions
|
| |
|
| |
|
| |
|
|
|
|
| |
This will reduce the number of helper functions that we need
|
| |
|
| |
|
| |
|
| |
|
| |
|