[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 12 commits: testsuite: Mark T23071 and T2047 as fragile on FreeBSD

Marge Bot (@marge-bot) gitlab at gitlab.haskell.org
Tue Feb 18 09:43:14 UTC 2025



Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC


Commits:
ef0e6cfc by Ben Gamari at 2025-02-17T19:20:09-05:00
testsuite: Mark T23071 and T2047 as fragile on FreeBSD

These inexplicably fail on FreeBSD on CI. Sadly I am unable to reproduce
this locally but regardless this is holding up Marge so I will mark them
as fragile for now.

Addresses #25751.

- - - - -
e6fee3a4 by Jens Petersen at 2025-02-18T04:42:29-05:00
hp2ps Utilities.c: include stdlib.h instead of extern malloc and realloc

- - - - -
3453318b by Rodrigo Mesquita at 2025-02-18T04:42:30-05:00
Inline join points for rhs without free vars

While investigating #25170, we ran into a program (T16473) that allocated 67%
more because of a join point that failed to inline.

Note [Duplicating join points] explains why we want to be conservative
when inlining join points, using as an example a join point that
captures a free variable `f` that becomes available in the continuation
`blah` for further optimisations, as opposed to being lambda-abstracted.

However, when the RHS of the join point has no free variables and is
trivial, the same argument does not apply, and there's nothing to gain
from preserving it.

On the contrary, not inlining these trivial join points such as
    $j f x = K f x |> co
can be actively harmful as they prevent useful optimisations from firing
on the known constructor application. #25723 is such an example.

Therefore, we've extended `uncondInlineJoin` to allow duplicating such closed
trivial join points. See the updated Note [Duplicating join points] for
further details.

Additionally, merge the guards in uncondInlineJoin for point DJ3(b) anad DJ3(c) of
Note [Duplicating join points] to avoid an unnecessary traversal in the
call to `collectArgs`; it's also more uniform.

Co-authored-by: Simon Peyton Jones <simon.peytonjones at gmail.com>

Fixes #25723

- - - - -
88803098 by M Farkas-Dyck at 2025-02-18T04:42:41-05:00
Scrub some partiality in `GHC.Tc.Gen.Match`.

In particular, we construct a list of the same length as another list, then loop over both and panic if their lengths are unequal. We can avoid this.

- - - - -
dac559ed by M Farkas-Dyck at 2025-02-18T04:42:41-05:00
Make list of `ParStmtBlock` in `ParStmt` `NonEmpty`.

In the ParStmt constructor Language.Haskell.Syntax.Expr.StmtLR, the 2nd argument, the list of ParStmtBlocks, must be NonEmpty; make it so.

- - - - -
8e55ad19 by M Farkas-Dyck at 2025-02-18T04:42:41-05:00
GHC.Tc.Gen.Match: Added type signatures for `loop` functions.

- - - - -
1c7e6e23 by sternenseemann at 2025-02-18T04:42:44-05:00
GHC: fix reference to function in Note [Target code interpreter]

As far as I could tell, setSessionDynFlags doesn't deal with hsc_interp.
Also added a backreference so this will be updated in the future.

- - - - -
0619e23f by sheaf at 2025-02-18T04:42:48-05:00
Account for skolem escape in mightEqualLater

This commit:

  1. Refactors checkTyEqRhs to allow it be called in pure contexts,
     which means it skips doing any on-the-fly promotion.
  2. Calls checkTyEqRhs in mightEqualLater to check whether it a
     MetaTv can unify with a RHS or whether that would cause e.g.
     skolem escape errors or concreteness errors.

Fixes #25744

- - - - -
19fcb49e by Sylvain Henry at 2025-02-18T04:42:52-05:00
Remove a bunch of Makefiles from old build system

- - - - -
b8f78d1d by M Farkas-Dyck at 2025-02-18T04:42:57-05:00
Totalize `GHC.HsToCore.Match.matchWrappers.initNablasGRHSs`.

Converting from `NonEmpty` to `[]` and back is totally needless.

- - - - -
dd5708d5 by Matthew Pickering at 2025-02-18T04:42:57-05:00
interpreter: Always print uniques for BCO_NAME labels

In the previous commit I omitted to include the unique, which still
makes it very difficult to trace back where the BCO came from.

- - - - -
9c5e61cf by Matthew Pickering at 2025-02-18T04:42:58-05:00
interpreter: Fix overflows and reentrancy in statistics calculation

1. Use unsigned long for counter, as they can easily overflow if you are
   running a long benchmark.
2. Make interp_shutdown reentrant by copying the command frequency table
   into an array.

Fixes #25756

- - - - -


49 changed files:

- compiler/GHC.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Driver/Env.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/ListComp.hs
- compiler/GHC/HsToCore/Match.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/Parser.y
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/StgToByteCode.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Errors/Types.hs
- compiler/GHC/Tc/Gen/Match.hs
- compiler/GHC/Tc/Solver/Default.hs
- compiler/GHC/Tc/Solver/Dict.hs
- compiler/GHC/Tc/Solver/InertSet.hs
- compiler/GHC/Tc/Solver/Monad.hs
- compiler/GHC/Tc/Solver/Solve.hs
- compiler/GHC/Tc/Utils/Unify.hs
- compiler/GHC/Tc/Zonk/Type.hs
- compiler/GHC/ThToHs.hs
- compiler/GHC/Types/Error/Codes.hs
- compiler/GHC/Types/Name.hs
- compiler/Language/Haskell/Syntax/Expr.hs
- docs/users_guide/9.14.1-notes.rst
- rts/Interpreter.c
- + testsuite/tests/perf/compiler/T25723.hs
- + testsuite/tests/perf/compiler/T25723.stdout
- testsuite/tests/perf/compiler/all.T
- testsuite/tests/primops/should_run/all.T
- testsuite/tests/rts/all.T
- testsuite/tests/simplCore/should_compile/T24229a.stderr
- testsuite/tests/simplCore/should_compile/T24229b.stderr
- + testsuite/tests/th/EmptyParStmt.hs
- + testsuite/tests/th/EmptyParStmt.stderr
- testsuite/tests/th/all.T
- + testsuite/tests/typecheck/should_compile/T25744.hs
- testsuite/tests/typecheck/should_compile/all.T
- − utils/deriveConstants/Makefile
- − utils/genprimopcode/Makefile
- − utils/ghc-pkg/Makefile
- − utils/hp2ps/Makefile
- utils/hp2ps/Utilities.c
- − utils/iserv/Makefile
- − utils/remote-iserv/Makefile
- − utils/runghc/Makefile
- − utils/unlit/Makefile


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/9c3751bbfe7a69f7ca3d44a48fd94da5e80cb974...9c5e61cf3c064609bc813d191655ccd8cd37693e

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/9c3751bbfe7a69f7ca3d44a48fd94da5e80cb974...9c5e61cf3c064609bc813d191655ccd8cd37693e
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20250218/694d6a31/attachment.html>


More information about the ghc-commits mailing list