| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This frees the Cmm data type from keeping a list of live global registers
in CmmCall which helps prepare for the CPS conversion phase.
CPS conversion does its own liveness analysis and takes input that should
not directly refer to parameter registers (e.g. R1, F5, D3, L2). Since
these are the only things which could occur in the live global register
list, CPS conversion makes that field of the CmmCall constructor obsolite.
Once the CPS conversion pass is fully implemented, global register saving
will move from codeGen into the CPS pass. Until then, this patch
is worth scrutinizing and testing to ensure it doesn't cause any performance
or correctness problems as the code passed to the backends by the CPS
converting will look very similar to the code that this patch makes codeGen
pass to the backend.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since a CmmCall returns CmmFormals which may include
global registers (and indeed one place in the code
returns the results of a CmmCall into BaseReg) and
since CPS conversion will change those return slots
into formal arguments for the continuation of the call,
CmmProc has to have CmmFormals for the formal arguments.
Oddly, the old code never made use of procedure arguments
so this change only effects the types and not any of the code.
(Because [] is both of type [LocalReg] and CmmFormals.)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
This has been a long-standing ToDo.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
- .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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
Info tables, like everything else in the text section, MUST NOT contain
pointers. A pointer is, by definition, position dependent and is therefore
fundamentally incompatible with generating position independent code.
Therefore, we have to store an offset from the info label to the string
instead of the pointer, just as we already did for other things referred
to by the info table (SRTs, large bitmaps, etc.)
|
| |
|
|
|
| |
We recently discovered that they aren't a win any more, and just cost
code size.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 the generated code for case-of-variable, test the tag of the
scrutinee closure and only enter if it is unevaluated. Also turn
*off* vectored returns.
|
| |
|
|
|
|
| |
In the generated code for case-of-variable, test the tag of the
scrutinee closure and only enter if it is unevaluated. Also turn
*off* vectored returns.
|
| | |
|
| |
|
|
| |
Only affects -fasm: gcc makes its own decisions about jump tables
|
| |
|
|
|
|
|
|
|
|
|
| |
With my as-yet-uncommitted changes to the demand analyzer, code got
generated for some programs that caused this assertion to fail. The
transformation I was doing was correct; it was the assertion that
wasn't. So, the assertion is removed.
This is actually Simon PJ's patch rather than mine, but I noticed that
it wasn't checked in and it seems completely safe to do so.
|
| |
|
|
|
|
|
| |
- Added HPCRIX support for passing tracer filename.
- Added thread tracing support.
- Cleaned up use of HsFFI.h
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This large checkin is the new ghc version of Haskell
Program Coverage, an expression-level coverage tool for Haskell.
Parts:
- Hpc.[ch] - small runtime support for Hpc; reading/writing *.tix files.
- Coverage.lhs - Annotates the HsSyn with coverage tickboxes.
- New Note's in Core,
- TickBox -- ticked on entry to sub-expression
- BinaryTickBox -- ticked on exit to sub-expression, depending
-- on the boolean result.
- New Stg level TickBox (no BinaryTickBoxes, though)
You can run the coverage tool with -fhpc at compile time.
Main must be compiled with -fhpc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GHC's code generator can only enter a closure if it's guaranteed
not to be a function. In the Dynamic module, we were using the
type (forall a.a) as the type to which the dynamic type was unsafely
cast:
type Obj = forall a.a
Gut alas this polytype was sometimes instantiated to (), something
like this (it only bit when profiling was enabled)
let y::() = dyn ()
in (y `cast` ..) p q
As a result, an ASSERT in ClosureInfo fired (hooray).
I've tided this up by making a new, primitive, lifted type Any, and
arranging that Dynamic uses Any, thus:
type Obj = ANy
While I was at it, I also arranged that when the type checker instantiates
un-constrained type variables, it now instantiates them to Any, not ()
e.g. length Any []
[There remains a Horrible Hack when we want Any-like things at arbitrary
kinds. This essentially never happens, but see comments with
TysPrim.mkAnyPrimTyCon.]
Anyway, this fixes Trac #905
|
| | |
|
| |
|
|
|
|
|
|
| |
A GHC binary can generally build either registerised or unregisterised
code, unless it is unregisterised only.
The previous changes broke this, but I think I've now restored it.
|
| |
|
|
|
|
|
|
| |
We were constructing info tables designed for TABLES_NEXT_TO_CODE,
but were building without TABLES_NEXT_TO_CODE.
This patch also fixes a bug when we are unregisterised on amd64 and
have code with an address above 2^32.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch is a start on removing import lists and generally tidying
up the top of each module. In addition to removing import lists:
- Change DATA.IOREF -> Data.IORef etc.
- Change List -> Data.List etc.
- Remove $Id$
- Update copyrights
- Re-order imports to put non-GHC imports last
- Remove some unused and duplicate imports
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This large commit combines several interrelated changes:
- IfaceSyn now contains actual Names rather than the special
IfaceExtName type. The binary interface file contains
a symbol table of Names, where each entry is a (package,
ModuleName, OccName) triple. Names in the IfaceSyn point
to entries in the symbol table.
This reduces the size of interface files, which should
hopefully improve performance (not measured yet).
The toIfaceXXX functions now do not need to pass around
a function from Name -> IfaceExtName, which makes that
code simpler.
- Names now do not point directly to their parents, and the
nameParent operation has gone away. It turned out to be hard to
keep this information consistent in practice, and the parent info
was only valid in some Names. Instead we made the following
changes:
* ImportAvails contains a new field
imp_parent :: NameEnv AvailInfo
which gives the family info for any Name in scope, and
is used by the renamer when renaming export lists, amongst
other things. This info is thrown away after renaming.
* The mi_ver_fn field of ModIface now maps to
(OccName,Version) instead of just Version, where the
OccName is the parent name. This mapping is used when
constructing the usage info for dependent modules.
There may be entries in mi_ver_fn for things that are not in
scope, whereas imp_parent only deals with in-scope things.
* The md_exports field of ModDetails now contains
[AvailInfo] rather than NameSet. This gives us
family info for the exported names of a module.
Also:
- ifaceDeclSubBinders moved to IfaceSyn (seems like the
right place for it).
- heavily refactored renaming of import/export lists.
- Unfortunately external core is now broken, as it relied on
IfaceSyn. It requires some attention.
|
| |
|
|
|
|
|
|
| |
Mon Sep 18 16:48:32 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au>
* GADT selector bugfix, bits of cleanup
Sun Aug 6 19:43:47 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au>
* GADT selector bugfix, bits of cleanup
Thu Jul 27 08:10:58 EDT 2006 kevind@bu.edu
|
| |
|
|
|
|
|
|
| |
Mon Sep 18 16:47:22 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au>
* fix some GADT record selector bugs (still some remaining)
Sun Aug 6 19:42:50 EDT 2006 Manuel M T Chakravarty <chak@cse.unsw.edu.au>
* fix some GADT record selector bugs (still some remaining)
Thu Jul 27 07:04:29 EDT 2006 kevind@bu.edu
|
| |
|
|
|
| |
Fixes ffi011(opt) on x86_64. I don't know why this has only just
appeared today, it's apparently been broken for some time.
|
| |
|
|
|
|
| |
This is mainly to restore the old behaviour, but also we shouldn't
normally need the package name in a cost centre because only the
"main" package normally has cost centres.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
static relative offsets (eg .long l1-l2) are restricted to 32 bits on
x86-64 due to lack of support in the linker. The codegen, NCG and
runtime work around this, using 32-bit offsets instead of 64.
However, we were missing a workaround for vector tables, and it
happened to work by accident because the offsets were always positive
and resolved by the assembler. The bug was exposed by using the NCG
to compile the RTS, where the offsets became negative, again by
accident.
|
| | |
|
|
|
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.
|
