| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Don't worry, this is not intended to enter the master.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
I change the type
data Count = One | Many
into
data Count = One | Many [String]
and use these list of strings (always sorted and nub'ed) to track the
various reasons why something is called many times.
|
| | |
|
| |
|
|
|
|
|
|
| |
The COUNTING_IND closure type is based on the (since removed) IND_PERM.
Some of the code is rather ad-hoc and likely in need of some refactoring
and clean-up before entering master (if it ever should), but it should
be good enough to play around with it and obtain some numbers.
|
| |
|
|
| |
and export Count abstractly (the constructors are not used anywhere).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also makes the behavior the same with frontend plugin errors --
frontend was failing with an exception (`CmdLineError`) while the
simplifier was just ignoring plugins. Now we abort with `CmdLineError`
in both cases with a slightly improved error message.
Test Plan:
- add tests (will add tests once #12197 is implemented)
- validate (done)
Reviewers: austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2334
GHC Trac Issues: #11690
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, following the TypeInType innovations,
each TyCon had two lists:
- tyConBinders :: [TyBinder]
- tyConTyVars :: [TyVar]
They were in 1-1 correspondence and contained
overlapping information. More broadly, there were many
places where we had to pass around this pair of lists,
instead of a single list.
This commit tidies all that up, by having just one list of
binders in a TyCon:
- tyConBinders :: [TyConBinder]
The new data types look like this:
Var.hs:
data TyVarBndr tyvar vis = TvBndr tyvar vis
data VisibilityFlag = Visible | Specified | Invisible
type TyVarBinder = TyVarBndr TyVar VisibilityFlag
TyCon.hs:
type TyConBinder = TyVarBndr TyVar TyConBndrVis
data TyConBndrVis
= NamedTCB VisibilityFlag
| AnonTCB
TyCoRep.hs:
data TyBinder
= Named TyVarBinder
| Anon Type
Note that Var.TyVarBdr has moved from TyCoRep and has been
made polymorphic in the tyvar and visiblity fields:
type TyVarBinder = TyVarBndr TyVar VisibilityFlag
-- Used in ForAllTy
type TyConBinder = TyVarBndr TyVar TyConBndrVis
-- Used in TyCon
type IfaceForAllBndr = TyVarBndr IfaceTvBndr VisibilityFlag
type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
-- Ditto, in interface files
There are a zillion knock-on changes, but everything
arises from these types. It was a bit fiddly to get the
module loops to work out right!
Some smaller points
~~~~~~~~~~~~~~~~~~~
* Nice new functions
TysPrim.mkTemplateKiTyVars
TysPrim.mkTemplateTyConBinders
which help you make the tyvar binders for dependently-typed
TyCons. See comments with their definition.
* The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
was making an assumption about the order of the kind variables in the
kind of GHC.Generics.(:.:). I fixed this; see TcGenGenerics.mkComp.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With TypeInType Richard combined ForAllTy and FunTy, but that was often
awkward, and yielded little benefit becuase in practice the two were
always treated separately. This patch re-introduces FunTy. Specfically
* New type
data TyVarBinder = TvBndr TyVar VisibilityFlag
This /always/ has a TyVar it. In many places that's just what
what we want, so there are /lots/ of TyBinder -> TyVarBinder changes
* TyBinder still exists:
data TyBinder = Named TyVarBinder | Anon Type
* data Type = ForAllTy TyVarBinder Type
| FunTy Type Type
| ....
There are a LOT of knock-on changes, but they are all routine.
The Haddock submodule needs to be updated too
|
| |
|
|
|
|
| |
..in typecheck/should_run/T7861
Was concealed behind the haddock perf noise
|
| |
|
|
|
|
|
| |
This reverts commit 0497ee504cc9ac5d6babee9b98bf779b3fc50b98.
Reason: See Trac #12191. I'm reverting pending Bartosz's
investigation of what went wrong.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`readProcessEnvWithExitCode` was added in
4d4d07704ee78221607a18b8118294b0aea1bac4, to start an external process
after making some modifications to the environment.
Since then, the `process` library has exposed
`readCreateProcessWithExitCode`, which allows for the refactoring we do
here.
Also change "en" to "C", as suggested in ticket:8825#comment:11.
Reviewed by: trofi
Differential Revision: https://phabricator.haskell.org/D2332
GHC Trac Issues: #8825
|
| |
|
|
|
|
|
| |
This makes it obvious that it's nondeterministic and hopefully
will prevent someone from using it accidentally.
GHC Trac: #4012
|
| |
|
|
| |
We can't tell whether the CAF is actually garbage or not.
|
| |
|
|
|
| |
This test didn't have a `.T` file, so the testsuite driver never ran it.
Luckily the features it tested for didn't break in the past 8 years.
|
| |
|
|
|
|
|
|
|
|
|
| |
This is a follow up to a74a3846c84ad55de3deeed8b2401a2ed514b2e1
, which made the same change but for the toplevel configure.ac.
Reviewed by: erikd
Differential Revision: https://phabricator.haskell.org/D2330
GHC Trac Issues: #11659
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Update submodule to accompany this commit:
commit 15b9bf4ba4ab47e6809bf2b3b36ec16e502aea72
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Sat Jun 11 23:49:27 2016 +0100
Improve typechecking of let-bindings
Sorry it's late!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `Ord Module` instance currently uses `Unique`s for comparison.
We don't want to use the `Unique` order because it can introduce nondeterminism.
This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic ordering
making `Ord Module` deterministic transitively.
I've run `nofib` and it doesn't make a measurable difference.
See also Note [ModuleEnv determinism and performance].
Test Plan:
./validate
run nofib: P112
Reviewers: simonpj, simonmar, austin, bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2030
GHC Trac Issues: #4012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The Ord instance for ModuleName is currently implemented in
terms of Uniques causing potential determinism problems.
I plan to change it to use the actual FastStrings and in
preparation for that I'm switching to UniqFM where it's
possible (you need *one* Unique per key, and you can't get
the keys back), so that the performance doesn't suffer.
Test Plan: ./validate
Reviewers: simonmar, austin, ezyang, bgamari
Reviewed By: bgamari
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2320
GHC Trac Issues: #4012
|
| |
|
|
|
| |
With the current implementation, it's nondeterministic
because Ord Module is nondeterministic.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Code already existed in the RTS to add thin library support for non-Windows
operating systems. This adds it to Windows as well.
ar thin libraries have the exact same format as normal archives except they
have a different magic string and they don't copy the object files into the
archive.
Instead each header entry points to the location of the object file on disk.
This is useful when a library is only created to satisfy a compile time dependency
instead of to be distributed. This saves the time required for copying.
Test Plan: ./validate and new test T11788
Reviewers: austin, bgamari, simonmar, erikd
Reviewed By: bgamari, simonmar
Subscribers: thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2323
GHC Trac Issues: #11788
|
| |
|
|
|
| |
This one omits the extension, thereby making GHC 8.0 produce
"GHC internal error".
|
| | |
|
| |
|
|
|
|
|
| |
This adds
*.patch
*.stackdump (Windows)
foo* (simonpj uses foo* for junk files)
|
| |
|
|
|
| |
During the kind-checking "knot" we have to be careful not
to print too eagerly.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
isPredTy can be called on ill-kinded types, especially (of course) if
there is a kind error. We don't wnat it to crash, but it was, in
piResultTy.
This patch introduces piResultTy_maybe, and uses it in isPredTy.
Ugh. I dislike this code. It's mainly used to know when we should
print types with '=>', and we should probably have a better way to
signal that.
|
| |
|
|
|
|
| |
We'd forgotten the variables free in the kind.
Ditto extendCvSubstWithClone
|
| |
|
|
|
| |
By spotting Refl coercions we can avoid building an awful
lot of CastTys. Simple and effective.
|
| |
|
|
|
|
|
|
|
|
|
| |
For type synonyms, we need to check that if the RHS has
kind Constraint, then we have -XConstraintKinds. For
some reason this was done in checkValidType, but it makes
more sense to do it in checkValidTyCon.
I can't remember quite why I made this change; maybe it fixes
a Trac ticket, but if so I forget which. But it's a modest
improvement anyway.
|
| |
|
|
|
| |
...thereby being able to replace substThetaUnchecked
with substTheta
|
| |
|
|
|
| |
I managed to eliminate the strange zonkQuantifiedTyVarOrType,
which is no longer used.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This major commit was initially triggered by #11339, but it spiraled
into a major review of the way in which type signatures for bindings
are handled, especially partial type signatures. On the way I fixed a
number of other bugs, namely
#12069
#12033
#11700
#11339
#11670
The main change is that I completely reorganised the way in which type
signatures in bindings are handled. The new story is in TcSigs
Note [Overview of type signatures]. Some specific:
* Changes in the data types for signatures in TcRnTypes:
TcIdSigInfo and new TcIdSigInst
* New module TcSigs deals with typechecking type signatures
and pragmas. It contains code mostly moved from TcBinds,
which is already too big
* HsTypes: I swapped the nesting of HsWildCardBndrs
and HsImplicitBndsrs, so that the wildcards are on the
oustide not the insidde in a LHsSigWcType. This is just
a matter of convenient, nothing deep.
There are a host of other changes as knock-on effects, and
it all took FAR longer than I anticipated :-). But it is
a significant improvement, I think.
Lots of error messages changed slightly, some just variants but
some modest improvements.
New tests
* typecheck/should_compile
* SigTyVars: a scoped-tyvar test
* ExPat, ExPatFail: existential pattern bindings
* T12069
* T11700
* T11339
* partial-sigs/should_compile
* T12033
* T11339a
* T11670
One thing to check:
* Small change to output from ghc-api/landmines.
Need to check with Alan Zimmerman
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch simply deletes code, the SigTv check in
occurCheckExpand. As the new comment says
In the past we also rejected a SigTv matched with a non-tyvar
But it is wrong to reject that for Givens;
and SigTv is in any case handled separately by
- TcUnify.checkTauTvUpdate (on-the-fly unifier)
- TcInteract.canSolveByUnification (main constraint solver)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The NUMA code was enabled whenever numa.h and numaif.h are detected.
Unfortunately, the hosts' header files were being detected even then
cross compiling in the absence of a target libnuma.
Fix that by relying on the the presence of libnuma instead of the
presence of the header files. The test for libnuma does `AC_TRY_LINK`
which will fail if the test program (compiled for the target) can't
be linked against libnuma.
Test Plan:
Build on x86_64/linux and make sure NUMA works and cross compile to
armhf/linux.
Reviewers: austin, bgamari, hvr, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2329
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
See #12031 for analysis, but essentially what happens is:
To sum up the issue, the reason this seems to go wrong is because
of how we initialize the `.bss` section for Windows in the runtime linker.
The first issue is where we calculate the zero space for the section:
```
zspace = stgCallocBytes(1, bss_sz, "ocGetNames_PEi386(anonymous bss)");
sectab_i->PointerToRawData = ((UChar*)zspace) - ((UChar*)(oc->image));
```
Where
```
UInt32 PointerToRawData;
```
This means we're stuffing a `64-bit` value into a `32-bit` one. Also `zspace`
can be larger than `oc->image`. In which case it'll overflow and
then get truncated in the cast.
The address of a value in the `.bss` section is then calculated as:
```
addr = ((UChar*)(oc->image))
+ (sectabent->PointerToRawData
+ symtab_i->Value);
```
If it does truncate then this calculation won't be correct (which is what is happening).
We then later use the value of `addr` as the `S` (Symbol) value for the relocations
```
S = (size_t) lookupSymbol_( (char*)symbol );
```
Now the majority of the relocations are `R_X86_64_PC32` etc.
e.g. They are guaranteed to fit in a `32-bit` value.
The `R_X86_64_64` introduced for these pseudo-relocations so they can use
the full `48-bit` addressing space isn't as lucky.
As for why it sometimes work has to do on whether the value is truncated or not.
`PointerToRawData` can't be changed because it's size is fixed by the PE specification.
Instead just like with the other platforms, we now use `section` on Windows as well.
This gives us a `start` parameter of type `void*` which solves the issue.
This refactors the code to use `section.start` and to fix the issues.
Test Plan: ./validate and new test added T12031
Reviewers: RyanGlScott, erikd, bgamari, austin, simonmar
Reviewed By: simonmar
Subscribers: thomie, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D2316
GHC Trac Issues: #12031, #11317
|
| |
|
|
|
| |
See #11204, this test sometimes fails and sometimes passes on OSX
which causes intermittent validate failures if it is run.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The recently added NUMA related functions were mistakenly defined
within a `#ifdef USE_LARGE_ADDRESS_SPACE` ... `#endif` block. Moving
them outside this block fixes the build on PowerPC and Arm Linux.
Test Plan: Build on PowerPC or Arm Linux
Reviewers: hvr, austin, bgamari, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2326
|
| | |
|
| |
|
|
|
|
|
|
| |
* Remove unused/old flags from the structs
* Update old comments
* Add missing flags to GHC.RTS
* Simplify GHC.RTS, remove C code and use hsc2hs instead
* Make ParFlags unconditional, and add support to GHC.RTS
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The aim here is to reduce the number of remote memory accesses on
systems with a NUMA memory architecture, typically multi-socket servers.
Linux provides a NUMA API for doing two things:
* Allocating memory local to a particular node
* Binding a thread to a particular node
When given the +RTS --numa flag, the runtime will
* Determine the number of NUMA nodes (N) by querying the OS
* Assign capabilities to nodes, so cap C is on node C%N
* Bind worker threads on a capability to the correct node
* Keep a separate free lists in the block layer for each node
* Allocate the nursery for a capability from node-local memory
* Allocate blocks in the GC from node-local memory
For example, using nofib/parallel/queens on a 24-core 2-socket machine:
```
$ ./Main 15 +RTS -N24 -s -A64m
Total time 173.960s ( 7.467s elapsed)
$ ./Main 15 +RTS -N24 -s -A64m --numa
Total time 150.836s ( 6.423s elapsed)
```
The biggest win here is expected to be allocating from node-local
memory, so that means programs using a large -A value (as here).
According to perf, on this program the number of remote memory accesses
were reduced by more than 50% by using `--numa`.
Test Plan:
* validate
* There's a new flag --debug-numa=<n> that pretends to do NUMA without
actually making the OS calls, which is useful for testing the code
on non-NUMA systems.
* TODO: I need to add some unit tests
Reviewers: erikd, austin, rwbarton, ezyang, bgamari, hvr, niteria
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2199
|
| | |
|
| |
|
|
| |
Use tauifyExpType rather than something hand-rolled
|
| |
|
|
| |
...about unarisation and unboxed tuples
|
| | |
|
| | |
|
