| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
The C-- parser was missing the "stdcall" calling convention for
foreign calls, but once added we can call {Enter,Leave}CricialSection
directly.
|
| | |
|
| | |
|
| |
|
|
|
| |
When calling EnterCriticalSection and LeaveCriticalSection from C--
code, we go via wrappers which use ccall (rather than stdcall).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ghc fails to build if you use an external gmp library. This is because
ghc requires the header file gmp.h, which used to be provided by the
internal gmp source code. The file gmp.h is no longer part of the
gmp source code, but is generated as part of the build procedure.
If an external gmp is specified, the internal gmp is not build and the
gmp.h file never gets generated.
Of course, it was a bad idea anyway to use a header file from a potentially
different version of the library.
The patch sets HAVE_LIB_GMP if the gmp library is found during configuration
and conditionalizes including the library header file on it.
|
| | |
|
| |
|
|
|
|
|
|
| |
There was an accidental endian-dependency in changes related to RET_FUN.
The changes in question weren't strictly necessary - they were left
over from the original workaround for the compacting GC problems, so
I've just reverted those changes in this patch, which should hopefully
fix the PPC problems.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| |
|
|
|
|
| |
On OS X, we have to #include <GMP/gmp.h> if we are using GMP.framework. Before
the recent GMP changes, gcc (incorrectly) used the gmp.h supplied by ghc but
that is gone now.
|
| |
|
|
|
| |
gmp is now in a top-level directory and we only have the tarball in the
darcs repo. It gets untarred if it is needed.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
When debugging the GC and storage manager we often want repeated runs
of the program to allocate memory at the same addresses, so that we
can set watch points. Unfortunately the OS doesn't always give us
memory at predictable addresses. This flag gives the OS a hint as to
where we would like our memory allocated. Previously I did this by
changing the HEAP_BASE setting in MBlock.h and recompiling, this patch
just adds a flag so I don't have to recompile.
|
| | |
|
| | |
|
| |
|
|
|
| |
We needed to turn some inline C functions and C macros into either
real C functions or C-- macros.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When the con_desc field of an info table was made into a relative
reference, this had the side effect of making the profiling fields
(closure_desc and closure_type) also relative, but only when compiling
via C, and the heap profiler was still treating them as absolute,
leading to crashes when profiling with -hd or -hy.
This patch fixes up the story to be consistent: these fields really
should be relative (otherwise we couldn't make shared versions of the
profiling libraries), so I've made them relative and fixed up the RTS
to know about this.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
foreign import ccall unsafe hs_hpc_write :: CString -> IO ()
foreign import ccall unsafe hs_hpc_read :: CString -> IO ()
These write a Hpc description of the state of the world to a file,
or read a description into the current Hpc tickbox subsystem.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
When -fbreak-on-exception is set, an exception will cause GHCi to
suspend the current computation and return to the prompt, where the
history of the current evaluation can be inspected (if we are in
:trace). This isn't on by default, because the behaviour could be
confusing: for example, ^C will cause a breakpoint. It can be very
useful for finding the cause of a "head []" or a "fromJust Nothing",
though.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
- .tix files are now a list of MixModule, which contain a hash of the contents of the .mix file.
- .mix files now have (the same) hash number.
This changes allow different binaries that use the same module compiled in the same way
to share coverage information.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that constructor info tables contain the name of the constructor,
we can generate useful heap profiles without requiring the whole
program and libraries to be compiled with -prof. So now, "+RTS -hT"
generates a heap profile for any program, dividing the profile by
constructor. It wouldn't be hard to add support for grouping
constructors by module, or to restrict the profile to certain
constructors/modules/packages.
This means that for the first time we can get heap profiles for GHCi,
which was previously impossible because the byte-code
interpreter and linker don't work with -prof.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ticky StgEntCounter structure was trying to be clever by using a
fixed-width 32-bit field for the registeredp value. But the code generators
are not up to handling structures packed tightly like this (on a 64-bit
architecture); result seg-fault on 64-bit.
Really there should be some complaint from the code generators, not simply
a seg fault.
Anyway I switched to using native words for StgEntCounter fields, and
now at least it works.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the result of Bernie Pope's internship work at MSR Cambridge,
with some subsequent improvements by me. The main plan was to
(a) Reduce the overhead for breakpoints, so we could enable
the feature by default without incurrent a significant penalty
(b) Scatter more breakpoint sites throughout the code
Currently we can set a breakpoint on almost any subexpression, and the
overhead is around 1.5x slower than normal GHCi. I hope to be able to
get this down further and/or allow breakpoints to be turned off.
This patch also fixes up :print following the recent changes to
constructor info tables. (most of the :print tests now pass)
We now support single-stepping, which just enables all breakpoints.
:step <expr> executes <expr> with single-stepping turned on
:step single-steps from the current breakpoint
The mechanism is quite different to the previous implementation. We
share code with the HPC (haskell program coverage) implementation now.
The coverage pass annotates source code with "tick" locations which
are tracked by the coverage tool. In GHCi, each "tick" becomes a
potential breakpoint location.
Previously breakpoints were compiled into code that magically invoked
a nested instance of GHCi. Now, a breakpoint causes the current
thread to block and control is returned to GHCi.
See the wiki page for more details and the current ToDo list:
http://hackage.haskell.org/trac/ghc/wiki/NewGhciDebugger
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
We changed the convention a while ago so that BaseReg is returned to
the scheduler in R1, because BaseReg may change during the run of a
thread, e.g. during a foreign call. A few places got missed,
mostly for very rare events.
Should fix concprog001, although I'm not able to reliably reproduce
the failure.
|
| |
|
|
| |
HANDLE is defined to be (void *) anyway, so this shouldn't hurt
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Tail-calls now branch to the end of the function after the call. This
stops gcc from trying to move instructions into the space immediately
after the call, which confuses the mangler.
|
| | |
|
| |
|
|
|
| |
We recently discovered that they aren't a win any more, and just cost
code size.
|
| |
|
|
| |
This is a simplification & minor optimisation for GHCi
|
| |
|
|
|
|
|
| |
This patch adds data constructor names into their info tables.
This is useful in the ghci debugger. It replaces the old scheme which
was based on tracking data con names in the linker.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Since thunks grew an extra padding word in GHC 6.6, closure_sizeW()
has been wrong for AP closures because it assumed compatible layout
between PAPs and APs. One symptom is that the compacting GC would
crash if it encountered an AP. APs conly crop up in GHCi or
when using asynchronous exceptions.
Fixes #1010
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following changes restore ticky-ticky profiling to functionality
from its formerly bit-rotted state. Sort of. (It got bit-rotted as part
of the switch to the C-- back-end.)
The way that ticky-ticky is supposed to work is documented in Section 5.7
of the GHC manual (though the manual doesn't mention that it hasn't worked
since sometime around 6.0, alas). Changes from this are as follows (which
I'll document on the wiki):
* In the past, you had to build all of the libraries with way=t in order to
use ticky-ticky, because it entailed a different closure layout. No longer.
You still need to do make way=t in rts/ in order to build the ticky RTS,
but you should now be able to mix ticky and non-ticky modules.
* Some of the counters that worked in the past aren't implemented yet.
I was originally just trying to get entry counts to work, so those should
be correct. The list of counters was never documented in the first place,
so I hope it's not too much of a disaster that some don't appear anymore.
Someday, someone (perhaps me) should document all the counters and what
they do. For now, all of the counters are either accurate (or at least as
accurate as they always were), zero, or missing from the ticky profiling
report altogether.
This hasn't been particularly well-tested, but these changes shouldn't
affect anything except when compiling with -fticky-ticky (famous last
words...)
Implementation details:
I got rid of StgTicky.h, which in the past had the macros and declarations
for all of the ticky counters. Now, those macros are defined in Cmm.h.
StgTicky.h was still there for inclusion in C code. Now, any remaining C
code simply cannot call the ticky macros -- or rather, they do call those
macros, but from the perspective of C code, they're defined as no-ops.
(This shouldn't be too big a problem.)
I added a new file TickyCounter.h that has all the declarations for ticky
counters, as well as dummy macros for use in C code. Someday, these
declarations should really be automatically generated, since they need
to be kept consistent with the macros defined in Cmm.h.
Other changes include getting rid of the header that was getting added to
closures before, and getting rid of various code having to do with eager
blackholing and permanent indirections (the changes under compiler/
and rts/Updates.*).
|
| |
|
|
| |
with instructions.
|
