Robert Hensing authored 3 years ago and Ben Gamari committed 3 years ago

(cherry picked from commit 2133ab18)

Robert Hensing authored 3 years ago and Ben Gamari committed 3 years ago

This gives users the choice to enable __compact_unwind sections
when linking. These were previously hardcoded to be removed.

This can be used to solved the problem "C++ does not catch
exceptions when used with Haskell-main and linked by ghc",
ghc/ghc#11829

It does not change the default behavior, because I can not
estimate the impact this would have.

When Apple first introduced the compact unwind ABI, a number of
open source projects have taken the easy route of disabling it,
avoiding errors or even just warnings shortly after its
introduction.

Since then, about a decade has passed, so it seems quite possible
that Apple itself, and presumably many programs with it, have
successfully switched to the new format, to the point where the
old __eh_frame section support is in disrepair. Perhaps we should
get along with the program, but for now we can test the waters
with this flag, and use it to fix packages that need it.

(cherry picked from commit 1496a2a7)

Tamar Christina authored 3 years ago and Ben Gamari committed 3 years ago

(cherry picked from commit 557db332)

We don't want to backport the number of commits which were necessary to
fix this issue for the 9.2.2 release so for now just turn it back into a
warning.

Partially reverts 0e5236ad

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

As described in Note [Wired-in exceptions are not CAFfy], a small set of
built-in exception closures get special treatment in the code generator,
being declared as non-CAFfy despite potentially containing CAF
references. The original intent of this treatment for the RTS to then
add StablePtrs for each of the closures, ensuring that they are not
GC'd. However, this logic was not applied consistently and eventually
removed entirely in 951c1fb0. This lead to #21141.

Here we fix this bug by reintroducing the StablePtrs and document the
status quo.

Closes #21141.

(cherry picked from commit 2ac45ba0)

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

(cherry picked from commit 18d7007e)

See #20781.

Metric increase due to new bytestring dependency on template-haskell
which causes more interface files to be read (due to family instances).

-------------------------
Metric Increase:
    T9630
-------------------------

These generally expect a particular word size.

(cherry picked from commit 44c08863)

C11 rule 6.3.1.1 dictates that all small integers used in expressions be
implicitly converted to `signed int`.  However, Cmm semantics require that the
width of the operands be preserved with zero-extension semantics. For
this reason we must recast sub-word arithmetic results as unsigned.

(cherry picked from commit e98dad1b)

As noted in Note [When in doubt, cast arguments as unsigned], we
must ensure that arguments have the correct signedness since some
operations (e.g. `%`) have different semantics depending upon
signedness.

(cherry picked from commit 0aeaa8f3)

As noted in Note [Zero-extending sub-word signed results] we must
explicitly zero-extend the results of sub-word-sized signed operations.

(cherry picked from commit ebaf7333)

Under C's implicit widening rules, the result of an operation like (a >>
b) where a::Word8 and b::Word will have type Word, yet we want Word.

(cherry picked from commit e19e9e71)

Here we rework the handling of sub-word operations in the AArch64
backend, fixing a number of bugs and inconsistencies. In short,
we now impose the invariant that all subword values are represented in
registers in zero-extended form. Signed arithmetic operations are then
responsible for sign-extending as necessary.

Possible future work:

 * Use `CMP`s extended register form to avoid burning an instruction
   in sign-extending the second operand.

 * Track sign-extension state of registers to elide redundant sign
   extensions in blocks with frequent sub-word signed arithmetic.

(cherry picked from commit adc7f108)

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

During the intial NCG development, GHC did not have support for
anything below Words.  As such the NCG didn't support any of this
either.  AArch64-Darwin however needs support for subword, as
arguments in excess of the first eight (8) passed via registers
are passed on the stack, and there in a packed fashion.  Thus
ghc learned about subword sizes.  This than lead us to gain
subword primops, and these subsequently highlighted deficiencies
in the AArch64 NCG.

This patch rectifies the ones I found through via the test-suite.
I do not claim this to be exhaustive.

Fixes: #19993

Metric Increase:
    T10421
    T13035
    T13719
    T14697
    T1969
    T9203
    T9872a
    T9872b
    T9872c
    T9872d
    T9961
    haddock.Cabal
    haddock.base
    parsing001

(cherry picked from commit d79530d1)

This is necessary for lint-correctness since we no longer allow such
shifts in Cmm.

(cherry picked from commit 9c65197e)

We might be loading, e.g., a 16- or 8-bit value, in which case the
register width is not reflective of the loaded element size.

(cherry picked from commit 7094f4fa)

There were found by the test-primops testsuite.

(cherry picked from commit 2f6565cf)

Previously primops.txt.pp stipulated that the word-size shift primops
were only defined for shift offsets in [0, word_size). However, there
was no further guidance for the definition of Cmm's sub-word size shift
MachOps.

Here we fix this by explicitly disallowing (checked in many cases by
CmmLint) shift operations where the shift offset is larger than the
shiftee. This is consistent with LLVM's shift operations, avoiding the
miscompilation noted in #20637.

(cherry picked from commit 35bbc251)

Previously we would emit the sign-extending LDS[HB] instructions for
sub-word loads. However, this is wrong, as noted in #20638.

(cherry picked from commit 78b78ac4)

Previously the constant-folding behavior for MO_S_Quot and MO_S_Rem
failed to narrow its arguments, meaning that a program like:

    %zx64(%quot(%lobits8(0x00e1::bits16), 3::bits8))

would be miscompiled. Specifically, this program should reduce as

                %lobits8(0x00e1::bits16)                 == -31
          %quot(%lobits8(0x00e1::bits16), 3::bits8)      == -10
    %zx64(%quot(%lobits8(0x00e1::bits16), 3::bits8))     == 246

However, with this bug the `%lobits8(0x00e1::bits16)` would instead
be treated as `+31`, resulting in the incorrect result of `75`.

(cherry picked from commit 94e197e3)
(cherry picked from commit 5b950a7f)

Handle the case of a shift larger than the width of the shifted value.
This is necessary since x86 applies a mask of 0x1f to the shift amount,
meaning that, e.g., `shr 47, $eax` will actually shift by
47 & 0x1f == 15.

See #20626.

(cherry picked from commit 31370f1a)
(cherry picked from commit 1724ac37)

Note [Matching lets] in GHC.Core.Rules claims the following:

> We use GHC.Core.Subst.substBind to freshen the binding, using an
> in-scope set that is the original in-scope variables plus the
> rs_bndrs (currently floated let-bindings).

However, previously the implementation didn't actually do extend the
in-scope set with rs_bndrs. This appears to be a regression which was
introduced by 4ff4d434.

Moreover, the originally reasoning was subtly wrong: we must rather use
the in-scope set from rv_lcl, extended with rs_bndrs, not that of
`rv_fltR`

Fixes #21122.

This reverts commit 8bbdba45.

Metric Decrease:
    T9872c
Metric Increase:
    T12545
    T18223

Note [Matching lets] in GHC.Core.Rules claims the following:

> We use GHC.Core.Subst.substBind to freshen the binding, using an
> in-scope set that is the original in-scope variables plus the
> rs_bndrs (currently floated let-bindings).

However, previously the implementation didn't actually do extend the
in-scope set with rs_bndrs. This appears to be a regression which was
introduced by 4ff4d434. Reintroduce
`rs_bndrs` into the in-scope set, ensuring that let-binders cannot
shadow one another due to rule rewrites.

Fixes #21122.

(cherry picked from commit 0f7dc670)

substExpr warns if it finds a LocalId that isn't in the in-scope set.
This patch extends the in-scope set to silence the warnings.  (It has
no effect on behaviour.)

(cherry picked from commit 25ca0b5a)

This patch fixes #19790 by making the rule matcher do on-the-fly
eta reduction.  See Note [Eta reduction the target] in GHC.Core.Rules

I found I also had to careful about casts when matching; see
Note [Casts in the target] and Note [Casts in the template]

Lots more comments and Notes in the rule matcher

(cherry picked from commit 590a2918)

There was a subtle error in the in-scope set during RULE matching,
which led to #20200 (not the original report, but the reports of
failures following an initial bug-fix commit).

This patch fixes the problem, and simplifies the code a bit.
In pariticular there was a very mysterious and ad-hoc in-scope set
extension in rnMatchBndr2, which is now moved to the right place,
namely in the Let case of match, where we do the floating.

I don't have a small repro case, alas.

(cherry picked from commit 4ff4d434)

This is the right thing to do, easy to do, and fixes
a second not-in-scope crash in #20200 (see !6302)
The problem occurs in the findBest test, which compares
two RULES.

Repro case in simplCore/should_compile/T20200a

(cherry picked from commit 7f217429)

Krzysztof Gogolewski authored 3 years ago and Ben Gamari committed 3 years ago

As #20200 showed, there was a call to lookupIdSubst during RULE
matching, where the variable being looked up wasn't in the InScopeSet.

This patch fixes the problem at source, by dealing separately with
nested and non-nested binders.

As a result we can change the trace call in lookupIdSubst to a
proper panic -- if it happens, we really want to know.

(cherry picked from commit 149bce42)

In the call to prepareBinding (in simplLazyBind), I had failed to
extend the in-scope set with the binders from body_floats1. As as
result, when eta-expanding deep inside prepareBinding we made up
an eta-binder that shadowed a variable free in body1.  Yikes.

It's hard to trigger this bug.  It showed up when I was working
on !5658, and I started using the in-scope set for eta-expansion,
rather than taking free variables afresh.  But even then it only
showed up when compiling a module in Haddock
   utils/haddock/haddock-api/src/Haddock/Interface/Rename.hs

Sadly Haddock is compiled without Core Lint, so we ultimately got
a seg-fault.  Lint nailed it fast once I realised that it was off.

There is some other tiny refactoring in this patch.

(cherry picked from commit 91eb1857)

Previously the eta-expansion would return lambdas interspersed with
casts; now the cast is just pushed to the outside: #20153.

This actually simplifies the code.

I also improved mkNthCo to account for SymCo, so that
   mkNthCo n (SymCo (TyConAppCo tc cos))
would work well.

(cherry picked from commit a199d653)

A partial backport of 299b7436.

sheaf authored 3 years ago and Ben Gamari committed 3 years ago

  The underlying bug was fixed by b8d98827, see MR !2477

(cherry picked from commit 48b0f17a)