| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This has several advantages:
- -fvia-C is consistent with -fasm with respect to FFI declarations:
both bind to the ABI, not the API.
- foreign calls can now be inlined freely across module boundaries, since
a header file is not required when compiling the call.
- bootstrapping via C will be more reliable, because this difference
in behavour between the two backends has been removed.
There is one disadvantage:
- we get no checking by the C compiler that the FFI declaration
is correct.
So now, the c-includes field in a .cabal file is always ignored by
GHC, as are header files specified in an FFI declaration. This was
previously the case only for -fasm compilations, now it is also the
case for -fvia-C too.
|
| | |
|
| | |
|
| |
|
|
| |
This required moving PackageId from PackageConfig to Module
|
| |
|
|
|
|
|
|
|
| |
Using -stubdir together with hierarchical modules, -fvia-C, and --make
is essentially broken in 6.6.x. Recently discovered by Cabal's use of
-stubdir.
Test cases: driver027/driver028 (I've updated them to use -fvia-C, in
order to test for this bug).
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
We used to pass the list of top-level foreign exported bindings to the
code generator so that it could create StablePtrs for them in the
stginit code. Now we don't use stginit unless profiling, and the
StablePtrs are generated by C functions marked with
attribute((constructor)). This patch removes various bits associated
with the old way of doing things, which were previously left in place
in case we wanted to switch back, I presume. Also I refactored
dsForeigns to clean it up a bit.
|
| | |
|
| |
|
|
|
|
|
| |
Compiling module Foo with -ddrop-asm-stats produces a file
called Foo.dump-asm-stats which will contain increasingly
interesting information.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you compiled a program with -ticky and ran it with:
./foo +RTS -rstderr -RTS
the result would be a segfault. This was because the RTS interprets stderr to
mean "use debugBelch to print out messages," and sets the ticky file pointer
to NULL as a result, but PrintTickyInfo (the function in Ticky.c that prints
out the ticky report) wasn't checking for NULL.
I changed PrintTickyInfo to check whether the ticky file pointer is NULL and
output to stderr if so.
Also removed an unused import from CodeOutput.lhs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.*).
|
| |
|
|
| |
in case anyone wants to see it)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This cleans up the package subsystem a little. There are some
changes to the GHC API as a result.
- GHC.init and GHC.initFromArgs are no longer necessary.
- GHC.newSession takes the root of the GHC tree as an argument
(previously passed to GHC.init).
- You *must* do GHC.setSessionDynFlags after GHC.newSession,
this is what loads the package database.
- Several global vars removed from SysTools
- The :set command in GHCi can now cause new packages to be loaded,
or can hide/ignore existing packages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
