| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes a fairly long-standing bug (dating back to 2015) in
RdrName.bestImport, namely
commit 9376249b6b78610db055a10d05f6592d6bbbea2f
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date: Wed Oct 28 17:16:55 2015 +0000
Fix unused-import stuff in a better way
In that patch got the sense of the comparison back to front, and
thereby failed to implement the unused-import rules described in
Note [Choosing the best import declaration] in RdrName
This led to Trac #13064 and #15393
Fixing this bug revealed a bunch of unused imports in libraries;
the ones in the GHC repo are part of this commit.
The two important changes are
* Fix the bug in bestImport
* Modified the rules by adding (a) in
Note [Choosing the best import declaration] in RdrName
Reason: the previosu rules made Trac #5211 go bad again. And
the new rule (a) makes sense to me.
In unravalling this I also ended up doing a few other things
* Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the
things that are used, rather than [AvailInfo]. This is simpler
and more direct.
* Rename greParentName to greParent_maybe, to follow GHC
naming conventions
* Delete dead code RdrName.greUsedRdrName
Bumps a few submodules.
Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27
Subscribers: rwbarton, carter
Differential Revision: https://phabricator.haskell.org/D5312
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: ./validate
Reviewers: goldfire, bgamari, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4367
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This switches the compiler/ component to get compiled with
-XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
modules.
This is motivated by the upcoming "Prelude" re-export of
`Semigroup((<>))` which would cause lots of name clashes in every
modulewhich imports also `Outputable`
Reviewers: austin, goldfire, bgamari, alanz, simonmar
Reviewed By: bgamari
Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
Differential Revision: https://phabricator.haskell.org/D3989
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are producing StgWords so foldl' is the natural choice. I'm not
sure how I didn't notice this when I wrote D1041.
Test Plan: Validate
Reviewers: austin, simonmar
Reviewed By: simonmar
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D2955
GHC Trac Issues: #7450
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would build up another `map (-N)` thunk
for every word in the bitmap. Now we strictly accumulate the position
and carry out a single ``map (`subtract` accum)``.
`Bitmap.intsToBitmap` showed up in the profile while compiling a
testcase of #7450 (namely a program containing a record type with large
number of fields which derived `Read`). The culprit was
`CmmBuildInfoTables.procpointSRT.bitmap`. On the testcase (with 4096
fields), the profile previously looked like,
```
total time = 307.94 secs (307943 ticks @ 1000 us, 1
processor)
total alloc = 336,797,868,056 bytes (excludes profiling
overheads)
COST CENTRE MODULE %time %alloc
lintAnnots CoreLint 17.2 25.8
procpointSRT.bitmap CmmBuildInfoTables 11.3 25.2
FloatOutwards SimplCore 7.5 1.6
flatten.lookup CmmBuildInfoTables 4.0 3.9
...
```
After this fix it looks like,
```
total time = 256.88 secs (256876 ticks @ 1000 us, 1
processor)
total alloc = 255,033,667,448 bytes (excludes profiling
overheads)
COST CENTRE MODULE %time %alloc
lintAnnots CoreLint 20.3 34.1
FloatOutwards SimplCore 9.1 2.1
flatten.lookup CmmBuildInfoTables 4.8 5.2
pprNativeCode AsmCodeGen 3.7 4.3
simplLetUnfolding Simplify 3.6 2.2
StgCmm HscMain 3.6 2.1
```
Signed-off-by: Ben Gamari <ben@smart-cactus.org>
Test Plan: Validate
Reviewers: austin, simonpj
Reviewed By: simonpj
Subscribers: thomie
Differential Revision: https://phabricator.haskell.org/D1041
GHC Trac Issues: #7450
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
reorganized, while following the convention, to
- place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
any `{-# OPTIONS_GHC #-}`-lines.
- Moreover, if the list of language extensions fit into a single
`{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
individual language extension. In both cases, try to keep the
enumeration alphabetically ordered.
(The latter layout is preferable as it's more diff-friendly)
While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
|
| | |
|
| |
|
|
|
| |
StgWord is a newtyped Word64, as it needed to be something that
has a UArray instance.
|
| | |
|
| |
|
|
| |
This frees wORD_SIZE up to be moved out of HaskellConstants
|
| |
|
|
| |
changes to unboxed tuple support
|
| |
|
|
|
| |
We only use it for "compiler" sources, i.e. not for libraries.
Many modules have a -fno-warn-tabs kludge for now.
|
|
|
* Move CgRep (private to old codgen) from SMRep to ClosureInfo
* Avoid using CgRep in new codegen
* Move SMRep and Bitmap from codeGen/ to cmm/
|
