Sergei Trofimovich authored 7 years ago and Ben Gamari committed 7 years ago

Unregisterised GHC can only use C as a target backend
(option used to be called -fvia-C). -fasm option was
ignored with a warhing, but not -fllvm.

jms noticed the failure when tried to use quick-cross
build flavour. quick-cross enables -fllvm in makefile.

  "inplace/bin/ghc-stage1" ... -fllvm
  ghc-stage1: panic! (the 'impossible' happened)
    (GHC version 8.0.2 for powerpc-unknown-linux):
          LlvmCodeGen.Ppr: Cross compiling without valid target info.

This change ignores -fllvm as well.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(cherry picked from commit 74615f41)

rwbarton authored 7 years ago and Ben Gamari committed 7 years ago

It was expensive, as the simplifier runs for many iterations,
and probably not very useful.

Test Plan: harbormaster

Reviewers: austin, bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, thomie

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

(cherry picked from commit 71916e1c)

Simon Marlow authored 7 years ago and Ben Gamari committed 7 years ago

When GHCi tries to find a shared lib, it calls "gcc --print-file-name"
to ask gcc where to find it.  But since we're looking for libraries,
we're really using the linker here, not the C compiler, so we should be
respecting the values of -pgml and -optl rather than -pgmc and -optc.

Test Plan: validate

Reviewers: bgamari, niteria, austin, hvr, erikd

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

(cherry picked from commit 30828799)

(cherry picked from commit 546c2a17)

As previously documented (88f5add0) wc's output
is inconsistent between Linux and BSDs. Use grep -c instead.

(cherry picked from commit cf74b677)

At long last fixes OS X build.

(cherry picked from commit 2f2622c6)

(cherry picked from commit fb7e5bd3)

rwbarton authored 7 years ago and Ben Gamari committed 7 years ago

The Join points commit (8d5cf8bf) introduced a space leak
somewhere in the simplifier. The extra strictness added in this commit
fixes the leak. Unfortunately I don't really understand the details.

Unfortunately, the extra strictness appears to result in more overall
allocations in some cases, even while the peak heap size decreases in others.

Test Plan: harbormaster

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

(cherry picked from commit e13419c5)

In Core, Constraint should be considered fully equal to
TYPE LiftedRep, in all ways. Accordingly, coreView should
unwrap Constraint to become TYPE LiftedRep. Of course, this
would be a disaster in the type checker.

So, where previously we used coreView in both the type checker
and in Core, we now have coreView and tcView, which differ only
in their treatment of Constraint.

Historical note: once upon a past, we had tcView distinct from
coreView. Back then, it was because newtypes were unwrapped in
Core but not in the type checker. The distinction is back, but
for a different reason than before.

This had a few knock-on effects:

 * The Typeable solver must explicitly handle Constraint to ensure
   that we produce the correct evidence.

 * TypeMap now respects the Constraint/Type distinction

Finished by: bgamari

Test Plan: ./validate

Reviewers: simonpj, austin, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie

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

(cherry picked from commit 6575f4b6)

This small refactoring, provoked by comment:18 on Trac #13426,
makes it so that simplExprF never gets a (Type ty) expression to
simplify, which in turn means that calls to exprType on its argument
will always succeed.

No change in behaviour.

(cherry picked from commit 29645274)

Joachim Breitner authored 7 years ago and Ben Gamari committed 7 years ago

These checks, introduced in cea71418
hugely inflated build logs, which incapitated perf.haskell.org.

According to Richard, the checks are useless and wrong, and that Ben
plans to investigate.
(https://phabricator.haskell.org/rGHCcea7141851ce653cb20207da3591d09e73fa396d#64647)

Until that happens, I remove them from the code.

(cherry picked from commit 03c7dd09)

Richard Eisenberg authored 7 years ago and Ben Gamari committed 7 years ago

Core Lint shouldn't check representations of types that don't
have representations.

test case: typecheck/should_compile/T13458

(cherry picked from commit cea71418)

This fixes Trac #13494, by improving

   commit e0ad55f8
   Author: Simon Peyton Jones <simonpj@microsoft.com>
   Date:   Mon Mar 27 10:32:08 2017 +0100

   Fix error-message suppress on given equalities

which in turn was a fix to #13446

(cherry picked from commit f88ac374)

Trac #13410 was failing because we had a RULE with a binder
   (c :: t~t)
and the /occurrences/ of c on the LHS were being optimised to Refl,
leaving a binder that would not be filled in by matching the LHS
of the rule.

I flirted with trying to ensure that occurrences (c :: t~t) are
not optimised to Relf, but that turned out to be fragile; it was
being done, for good reasons, in multiple places, including
  - TyCoRep.substCoVarBndr
  - Simplify.simplCast
  - Corecion.mkCoVarCo

So I fixed it in one place by making Rules.matchN deal happily
with an unbound binder (c :: t~t).  Quite easy.  See "Coercion
variables" in Note [Unbound RULE binders] in Rules.

In addition, I needed to make CoreLint be happy with an bound
RULE binder that is a Relf coercion variable

In debugging this, I was perplexed that occurrences of a variable
(c :: t~t) mysteriously turned into Refl.  I found out how it
was happening, and decided to move it:

* In TyCoRep.substCoVarBndr, do not substitute Refl for a
  binder (c :: t~t).

* In mkCoVarCo do not optimise (c :: t~t) to Refl.

Instead, we do this optimisation in optCoercion (specifically
opt_co4) where, surprisingly, the optimisation was /not/
being done.  This has no effect on what programs compile;
it just moves a relatively-expensive optimisation to optCoercion,
where it seems more properly to belong.  It's actually not clear
to me which is really "better", but this way round is less
surprising.

One small simplifying refactoring

* Eliminate TyCoRep.substCoVarBndrCallback, which was only
  called locally.

(cherry picked from commit 8674883c)

Do not attempt to typecheck both directions of an
implicitly-bidirectional pattern synonym simultanously,
as we were before.  Instead, the builder is typechecked
when we typecheck the code for the builder, which was
of course happening already, even in both bidirectional
cases.

See Note [Checking against a pattern signature], under
"Existential type variables".

(cherry picked from commit b5c81203)

Sergei Trofimovich authored 7 years ago and Ben Gamari committed 7 years ago

The #13491 manifests best when we try to crosscompile
from 32-bit (i386-linux) to 64-bit (powerpc64-linux)
system:
    ./configure --target=powerpc64-unknown-linux-gnu

The build fails at assembly time:
  "inplace/bin/ghc-stage1" ...  -c rts/StgStartup.cmm
    /tmp/ghc19687_0/ghc_4.s: Assembler messages:

    /tmp/ghc19687_0/ghc_4.s:11:0: error:
         Error: unknown pseudo-op: `.l'
       |
    11 | .L<\x00>4:
       | ^

That happens because UNIQUE_BITS is defined in terms
of WORD_SIZE_IN_BITS macro:
    #define UNIQUE_BITS (WORD_SIZE_IN_BITS - 8)

WORD_SIZE_IN_BITS is 64 bits (equals to target value)
while ghc-stage1 is still running on i386-linux

The fix is to stop relying on target macros and use
host's 'sizeof (HsInt)' and 'finiteBitSize' way to
determine unique layout.

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: build i386-to-powerpc64 crosscompiler

Reviewers: rwbarton, austin, bgamari

Reviewed By: bgamari

Subscribers: RyanGlScott, thomie

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

(cherry picked from commit 01b062ec)

Moritz Angermann authored 7 years ago and Ben Gamari committed 7 years ago

- Better test for SHT_INIT_ARRAY than openbsd_HOST_OS
  This is actually bens patch:
  https://gist.github.com/bgamari/c846e6a5f2cd988716cd5e36c68d5bef
- linux-android defines.
- No need for -lpthread on OSAndroid
  However, I’m confused why we do not use the AC NEED_PTHREAD_LIB
  value here?
- Use mmap on android
- Support `none` vendor.

Reviewers: austin, hvr, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, erikd

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

(cherry picked from commit 924a65fc)

Moritz Angermann authored 7 years ago and Ben Gamari committed 7 years ago

Reviewers: austin, hvr, rwbarton, bgamari

Reviewed By: rwbarton, bgamari

Subscribers: rwbarton, thomie, erikd

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

(cherry picked from commit 81f5b6ec)

Matthew Pickering authored 7 years ago and Ben Gamari committed 7 years ago

(cherry picked from commit 5025fe24)

The commit 67465497
    Author: Richard Eisenberg <eir@cis.upenn.edu>
    Date:   Fri Dec 11 18:19:53 2015 -0500

    Add kind equalities to GHC.

added this entirely bogus code to Simplify.simplLam:

    env' | Coercion co <- arg
         = extendCvSubst env bndr co
         | otherwise
         = env

It's bogus because 'co' is an 'InCoercion', but a CvSubst should have
only OutCoercions in it.  Moreover, completeBind does the job nicely.

This led to an ASSERT failure in an experimental branch; but I have
not got a repro case that works on HEAD.  But still, the patch deletes
code and fixes a bug, so it must be good.

The only mystery is why Richard added it in the first place :-).
I hope I'm not missing anything.  But it validates fine.

(cherry picked from commit de4723fd)

I'd got the logic slightly wrong when reporting type errors
for insoluble 'given' equalities.  We suppress insoluble givens
under some circumstances (see Note [Given errors]), but we then
suppressed subsequent 'wanted' errors because the (suppressed)
'given' error "won".  Result: no errors at all :-(.

This patch fixes it and
 - Renames TcType.isTyVarUnderDatatype to the more
   perspicuous TcType.isInsolubleOccursCheck

In doing this I realise that I don't understand why we need
to keep the insolubles partitioned out separately at all...
but that is for another day.

(cherry picked from commit e0ad55f8)

This partly fixes Trac #13441, at least for the explicitly
bidirectional case.

See Note [Checking against a pattern signature], the part about
"Existential type variables".

Alas, the implicitly-bidirectional case is still not quite right, but
at least there is a workaround by making it explicitly bidirectional.

(cherry picked from commit 7c7479d0)

(cherry picked from commit 7e1c492d)

I was getting
  docs/users_guide/glasgow_exts.rst:12783:
     WARNING: Title underline too short.

  ``COLUMN`` pragma
  ---------------

So I lengthened the row of hyphens.

(cherry picked from commit af33073c)

In fixing Trac #13337, and introducing solveSomeEqualities,
Richard introduce the higher-order function tc_hs_sig_type_x,
with a solver as its argument.

It turned out that there was a much simpler way to do the
same thing, which this patch implements.  Less code, easier
to grok.  No change in behaviour though.

(cherry picked from commit 1e06d8b8)

Simon Marlow authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: validate

Reviewers: bgamari, austin, erikd

Subscribers: rwbarton, thomie

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

(cherry picked from commit c77551ab)

Simon Marlow authored 7 years ago and Ben Gamari committed 7 years ago

Summary: See comments for details.

Test Plan: validate

Reviewers: mpickering, bgamari, austin, erikd

Subscribers: rwbarton, thomie

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

(cherry picked from commit 074d13eb)

This fixes #13489.

(cherry picked from commit b04ded8f)

Simon Marlow authored 8 years ago and Ben Gamari committed 7 years ago

* In stg_ap_0_fast, if we're evaluating a thunk, the thunk might
  evaluate to a function in which case we may have to adjust its CCS.

* The interpreter has its own implementation of stg_ap_0_fast, so we
  have to do the same shenanigans with creating empty PAPs and copying
  PAPs there.

* GHCi creates Cost Centres as children of CCS_MAIN, which enterFunCCS()
  wrongly assumed to imply that they were CAFs.  Now we use the is_caf
  flag for this, which we have to correctly initialise when we create a
  Cost Centre in GHCi.

(cherry picked from commit 3a18baff)

Simon Marlow authored 8 years ago and Ben Gamari committed 7 years ago

I forgot to account for BCOs, which have a different layout from
functions.  This caused crashes when using profiling with GHCi (via
-fexternal-interpreter -prof), which unfortunately is not tested at all
by validate, even when profiling is enabled.  I'm going to add some
testing that would have caught this in a separate patch.

Test Plan:
```
cd nofib/spectral/puzzle && make NoFibWithGHCi=YES
EXTRA_RUNTEST_OPTS='-fexternal-interpreter -prof'
```
New testsuite tests coming in a separate diff.

Reviewers: niteria, austin, erikd, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #5654

(cherry picked from commit 2a02040b)

Simon Marlow authored 8 years ago and Ben Gamari committed 7 years ago

This fixes some cases of wrong stacks being generated by the profiler.
For background and details on the fix see
`Note [Evaluating functions with profiling]` in `rts/Apply.cmm`.

This does have an impact on allocations for some programs when
profiling.  nofib results:

```
   k-nucleotide          +0.0%     +8.8%    +11.0%    +11.0%      0.0%
         puzzle          +0.0%    +12.5%     0.244     0.246      0.0%
      typecheck           0.0%     +8.7%    +16.1%    +16.2%      0.0%
------------------------------------------------------------------------
--------
            Min          -0.0%     -0.0%    -34.4%    -35.5%    -25.0%
            Max          +0.0%    +12.5%    +48.9%    +49.4%    +10.6%
 Geometric Mean          +0.0%     +0.6%     +2.0%     +1.8%     -0.3%

```

But runtimes don't seem to be affected much, and the examples I looked
at were completely legitimate.  For example, in puzzle we have this:

```
position :: ItemType -> StateType ->  BankType
position Bono = bonoPos
position Edge = edgePos
position Larry = larryPos
position Adam = adamPos
```

where the identifiers on the rhs are all record selectors.  Previously
the profiler gave a stack that looked like

```
  position
  bonoPos
  ...
```

i.e. `bonoPos` was at the same level of the call stack as `position`,
but now it looks like

```
  position
   bonoPos
   ...
```

I used the normaliser from the testsuite to diff the profiling output
from other nofib programs and they all looked better.

Test Plan:
* the broken test passes
* validate
* compiled and ran all of nofib, measured perf, diff'd several .prof
files

Reviewers: niteria, erikd, austin, scpmw, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

GHC Trac Issues: #5654, #10007

(cherry picked from commit 394231b3)

Joachim Breitner authored 7 years ago and Ben Gamari committed 7 years ago

As #13479 shows, there are corner cases where the simplifier decides to
not eta-expand a function as much as its call arity would suggest, but
instead transforms the code that the call arity annotation becomes a
lie.

As the call arity information is only meant to be used by the
immediatelly following simplifier run, it makes sense to simply zap the
information there.

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

(cherry picked from commit e07211f7)

In initTc, if the computation fails with an exception, we
should not complain about unsolved constraints.

Fixes Trac #13466.

(cherry picked from commit feca929b)

(cherry picked from commit d5847cfe)

See #13481.

(cherry picked from commit 140a2d1c)

Otherwise we run it in the hpc way, which outputs different Core.

(cherry picked from commit 23da02b1)

rwbarton authored 7 years ago and Ben Gamari committed 7 years ago

Test Plan: validate

Reviewers: austin, bgamari, dfeuer

Reviewed By: dfeuer

Subscribers: dfeuer, thomie

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

(cherry picked from commit 14b46a55)

(cherry picked from commit a1b7e866)