GitLab

Due to Stephanie Weirich, Dan Licata, John Hughes, Matt Might

'-rdynamic' is currently only a link-time option.
Does not make sense for ghci without major changes.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Known Issue #7297
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

More modular, less code.  No change in behaviour.

* T1969 improves, perhaps because of better specialiation

* T5642 (a bizarre case) worsens, because we get lots and lots
  of specialisations of imported functions for the lots and
  lots of data types T5642 declares

Doing so pushes bindings nearer their use site and hence makes
them more likely to be strict. These bindings might only show
up after the inlining from simplification.  Example in fulsom,
Csg.calc, where an arg of timesDouble thereby becomes strict.

Very few programs are affected, but it's basically good news.

        Program           Size    Allocs   Runtime   Elapsed  TotalMem
--------------------------------------------------------------------------------
            fft          -0.2%     +1.3%      0.06      0.06    -10.0%
         fulsom          -0.0%     -2.6%     -4.3%     -4.7%     -6.7%
         simple          +0.0%     -0.8%      0.0%      0.0%      0.0%
--------------------------------------------------------------------------------
            Min          -0.5%     -2.6%     -4.5%     -4.7%    -10.0%
            Max          +0.1%     +1.3%     +3.3%     +3.4%     +2.6%
 Geometric Mean          -0.0%     -0.0%     -0.6%     -0.6%     -0.2%

The lossage in fft is the loss of detecting a common sub-expression,
and can be fixed by doing earlier CSE.  But that is in any case a bit
of a fluke so I don't mind losing it in exchange for this more reliable
gain.

The new function TidyPgm.trimAutoRules discards bindings and
rules that were useful, but now have served their purpose.

See Note [Trimming auto rules] in TidyPgm

We were missing the free variables of rules etc.  It's correct
for Rec but wrong for NonRec.  I'm not sure how this bug hasn't
bitten us before, but it cropped up when I was doing trimAutoRules.

This flag specialises any imported overloaded function that has an
unfolding, whether or not it was marked INLINEABLE.

We get a lot of orphan SPEC rules as a result, but that doesn't matter
provided we don't treat orphan auto-generated rules as causing the module
itself to be an orphan module.  See Note [Orphans and auto-generated rules]
in MkIface.

I this this arises from my de-orphaning the Enum Word instance

Specialise liftM, foldM, etc, and make them specialisable
for new monads at their call sites by using INLINEABLE

A class op applied to a dictionary doesn't do much work, so it's not
a great idea to float it out (except possibly to the top level.

See Note [Floating over-saturated applications] in SetLevels

I also renamed "floatOutPartialApplications" to "floatOutOverSatApps";
the former is deeply confusing, since there is no partial application
involved -- quite the reverse, it is *over* saturated.

This just avoids an unnecessary orphan instance.
All the other instances for "earlier" types are in GHC.Enum already.

These instances are quite common, so it's good to have
pre-specialised versions available

This fixes a long-standing bug: Trac #6056.  The trouble was that
INLINEABLE "used up" the unfolding for the Id, so it couldn't be
worker/wrapper'd by the strictness analyser.

This patch allows the w/w to go ahead, and makes the *worker* INLINEABLE
instead, so it can later be specialised.

However, that doesn't completely solve the problem, because the dictionary
argument (which the specialiser treats specially) may be strict and
hence unpacked by w/w, so now the worker won't be specilialised after all.

Solution: never unpack dictionary arguments, which is done by the isClassTyCon
          test in WwLib.deepSplitProductType_maybe

CoreSyn.maybeUnfoldingTemplate is used mainly when specialising,
so make DFunUnfoldings respond to it makes it possible to specialise
them properly.

There are two main refactorings here

1.  Move the uf_arity field
       out of CoreUnfolding
       into UnfWhen
    It's a lot tidier there.  If I've got this right, no behaviour
    should change.

2.  Define specUnfolding and use it in DsBinds and Specialise
     a) commons-up some shared code
     b) makes sure that Specialise correctly specialises DFun
        unfoldings (which it didn't before)

The two got put together because both ended up interacting in the
specialiser.

They cause zero difference to nofib.

This reverts commit 623883f1.

The commit a93ab43a


    driver: pass '-fPIC' option to assembler as well
fixes shared libraries on sparc at least on linux.

Properly fixes Issue #8857
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Summary:
Before the patch '-fPIC' was passed only to C compiler,
but not to assembler itself.

It led to runtime crash in GHC_DYNAMIC_PROGRAMS=YES mode
on sparc32.

Technical details are in 'Note [-fPIC for assembler]'.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: validate on sparc

Reviewers: simonmar, austin, kgardas

Reviewed By: austin

Subscribers: simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D177

Summary:
On amd64/UNREG build there is many failing tests trying
to deal with 'Integer' types.

Looking at 'integerConversions' test I've observed
invalid C code generated by GHC.

Cmm code
    CInt a = -1; (a == -1)
yields 'False' with optimisations enabled via the following C code:
    StgWord64 a = (StgWord32)0xFFFFffffFFFFffffu; (a == 0xFFFFffffFFFFffffu)

The patch fixes it by shrinking emitted literals to required sizes:
    StgWord64 a = (StgWord32)0xFFFFffffu; (a == 0xFFFFffffu)

Thanks to Reid Barton for tracking down and fixing the issue.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: validate on UNREG build (amd64, x86)

Reviewers: simonmar, rwbarton, austin

Subscribers: hvr, simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D173

In particular mention that they aren't allowed for record updates.

Triggered by Trac #9437

of named fields, whereas the code in RnPat.rnHsRecFields is
much better set up to do so.

Both easily fixed.

This patch corrects an egregious error introduced by:

  commit 022f8750
  Author: Simon Peyton Jones <simonpj@microsoft.com>
  Date:   Thu May 15 16:07:04 2014 +0100

    Refactoring around TyCon.isSynTyCon

    * Document isSynTyCon better
    * Add isTypeSyonymTyCon for regular H98 type synonyms
    * Use isTypeSynonymTyCon rather than isSynTyCon where
      the former is really intended

At this particular spot in TcValidity we really do mean
isSynTyCon and not isTypeSynonymTyCon.

Fixes Trac #9433

Un-saturated type-family and type-synonym applications are
detected in the front end, but for some reason Lint wasn't
looking for them.

I came across this when wondering why Trac #9433 didn't give
a Core Lint error

This patch should make no change in behaviour.

 * Make RhsInfo into a record

 * Include ri_rhs_usg, which previously travelled around separately

 * Introduce specRec, specNonRec, and
   make them return [OneSpec] rather than SpecInfo

This long-standing and egregious bug meant that call information was
being gratuitously copied, leading to an exponential blowup in the
number of calls to be examined when function definitions are deeply
nested.  That is what has been causing the blowup in SpecConstr's
running time, not (as I had previously supposed) generating very large code.

See Note [spec_usg includes rhs_usg]

This is just a small refactoring that makes the code a bit clearer,
using a data type instead of a triple.  We get better pretty-printing too.

The main motivation is that user-style output assumes that everything has been
tidied, not enough uniques are printed by default.

The downside is that pprTrace output now has module prefixes which can be overwhelming,
but -dsuppress-module-prefixes will suppress them.

Exposes Issue #9512 on amd64
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Effective immediately, pushing to libraries/{directory,process} requires
pushing to ssh://git@github.com/haskell/{directory.process}.git. This has
been done now even though there's no scripted tooling yet as the GitHub repo
was already getting issues filed.