[Git][ghc/ghc][wip/T21470] 16 commits: Introduce a standard thunk for allocating strings

Simon Peyton Jones (@simonpj) gitlab at gitlab.haskell.org
Wed Oct 26 10:00:32 UTC 2022



Simon Peyton Jones pushed to branch wip/T21470 at Glasgow Haskell Compiler / GHC


Commits:
86e6549e by Ömer Sinan Ağacan at 2022-10-22T07:41:30-04:00
Introduce a standard thunk for allocating strings

Currently for a top-level closure in the form

    hey = unpackCString# x

we generate code like this:

    Main.hey_entry() //  [R1]
             { info_tbls: [(c2T4,
                            label: Main.hey_info
                            rep: HeapRep static { Thunk }
                            srt: Nothing)]
               stack_info: arg_space: 8 updfr_space: Just 8
             }
         {offset
           c2T4: // global
               _rqm::P64 = R1;
               if ((Sp + 8) - 24 < SpLim) (likely: False) goto c2T5; else goto c2T6;
           c2T5: // global
               R1 = _rqm::P64;
               call (stg_gc_enter_1)(R1) args: 8, res: 0, upd: 8;
           c2T6: // global
               (_c2T1::I64) = call "ccall" arg hints:  [PtrHint,
                                                        PtrHint]  result hints:  [PtrHint] newCAF(BaseReg, _rqm::P64);
               if (_c2T1::I64 == 0) goto c2T3; else goto c2T2;
           c2T3: // global
               call (I64[_rqm::P64])() args: 8, res: 0, upd: 8;
           c2T2: // global
               I64[Sp - 16] = stg_bh_upd_frame_info;
               I64[Sp - 8] = _c2T1::I64;
               R2 = hey1_r2Gg_bytes;
               Sp = Sp - 16;
               call GHC.CString.unpackCString#_info(R2) args: 24, res: 0, upd: 24;
         }
     }

This code is generated for every string literal. Only difference between
top-level closures like this is the argument for the bytes of the string
(hey1_r2Gg_bytes in the code above).

With this patch we introduce a standard thunk in the RTS, called
stg_MK_STRING_info, that does what `unpackCString# x` does, except it
gets the bytes address from the payload. Using this, for the closure
above, we generate this:

    Main.hey_closure" {
        Main.hey_closure:
            const stg_MK_STRING_info;
            const 0; // padding for indirectee
            const 0; // static link
            const 0; // saved info
            const hey1_r1Gg_bytes; // the payload
    }

This is much smaller in code.

Metric Decrease:
    T10421
    T11195
    T12150
    T12425
    T16577
    T18282
    T18698a
    T18698b

Co-Authored By: Ben Gamari <ben at well-typed.com>

- - - - -
1937016b by Andreas Klebinger at 2022-10-22T07:42:06-04:00
hadrian: Improve error for wrong key/value errors.

- - - - -
11fe42d8 by Vladislav Zavialov at 2022-10-23T00:11:50+03:00
Class layout info (#19623)

Updates the haddock submodule.

- - - - -
f0a90c11 by Sven Tennie at 2022-10-24T00:12:51-04:00
Pin used way for test cloneMyStack (#21977)

cloneMyStack checks the order of closures on the cloned stack. This may
change for different ways. Thus we limit this test to one way (normal).

- - - - -
0614e74d by Aaron Allen at 2022-10-24T17:11:21+02:00
Convert Diagnostics in GHC.Tc.Gen.Splice (#20116)

Replaces uses of `TcRnUnknownMessage` in `GHC.Tc.Gen.Splice` with
structured diagnostics.

closes #20116

- - - - -
8d2dbe2d by Andreas Klebinger at 2022-10-24T15:59:41-04:00
Improve stg lint for unboxed sums.

It now properly lints cases where sums end up distributed
over multiple args after unarise.

Fixes #22026.

- - - - -
41406da5 by Simon Peyton Jones at 2022-10-25T18:07:03-04:00
Fix binder-swap bug

This patch fixes #21229 properly, by avoiding doing a
binder-swap on dictionary Ids.  This is pretty subtle, and explained
in Note [Care with binder-swap on dictionaries].

Test is already in simplCore/should_run/T21229

This allows us to restore a feature to the specialiser that we had
to revert: see Note [Specialising polymorphic dictionaries].
(This is done in a separate patch.)

I also modularised things, using a new function scrutBinderSwap_maybe
in all the places where we are (effectively) doing a binder-swap,
notably

* Simplify.Iteration.addAltUnfoldings
* SpecConstr.extendCaseBndrs

In Simplify.Iteration.addAltUnfoldings I also eliminated a guard
    Many <- idMult case_bndr
because we concluded, in #22123, that it was doing no good.

- - - - -
5a997e16 by Simon Peyton Jones at 2022-10-25T18:07:03-04:00
Make the specialiser handle polymorphic specialisation

Ticket #13873 unexpectedly showed that a SPECIALISE pragma made a
program run (a lot) slower, because less specialisation took place
overall. It turned out that the specialiser was missing opportunities
because of quantified type variables.

It was quite easy to fix. The story is given in
    Note [Specialising polymorphic dictionaries]

Two other minor fixes in the specialiser

* There is no benefit in specialising data constructor /wrappers/.
  (They can appear overloaded because they are given a dictionary
  to store in the constructor.)  Small guard in canSpecImport.

* There was a buglet in the UnspecArg case of specHeader, in the
  case where there is a dead binder. We need a LitRubbish filler
  for the specUnfolding stuff.  I expanded
  Note [Drop dead args from specialisations] to explain.

There is a 4% increase in compile time for T15164, because we generate
more specialised code.  This seems OK.

Metric Increase:
    T15164

- - - - -
7f203d00 by Sylvain Henry at 2022-10-25T18:07:43-04:00
Numeric exceptions: replace FFI calls with primops

ghc-bignum needs a way to raise numerical exceptions defined in base
package. At the time we used FFI calls into primops defined in the RTS.
These FFI calls had to be wrapped into hacky bottoming functions because
"foreign import prim" syntax doesn't support giving a bottoming demand
to the foreign call (cf #16929).

These hacky wrapper functions trip up the JavaScript backend (#21078)
because they are polymorphic in their return type. This commit
replaces them with primops very similar to raise# but raising predefined
exceptions.

- - - - -
0988a23d by Sylvain Henry at 2022-10-25T18:08:24-04:00
Enable popcount rewrite rule when cross-compiling

The comment applies only when host's word size < target's word size.
So we can relax the guard.

- - - - -
a2f53ac8 by Sylvain Henry at 2022-10-25T18:09:05-04:00
Add GHC.SysTools.Cpp module

Move doCpp out of the driver to be able to use it in the upcoming JS backend.

- - - - -
1fd7f201 by Ben Gamari at 2022-10-25T18:09:42-04:00
llvm-targets: Add datalayouts for big-endian AArch64 targets

Fixes #22311.

Thanks to @zeldin for the patch.

- - - - -
f5a486eb by Krzysztof Gogolewski at 2022-10-25T18:10:19-04:00
Cleanup String/FastString conversions

Remove unused mkPtrString and isUnderscoreFS.
We no longer use mkPtrString since 1d03d8bef96.

Remove unnecessary conversions between FastString and String and back.

- - - - -
f7bfb40c by Ryan Scott at 2022-10-26T00:01:24-04:00
Broaden the in-scope sets for liftEnvSubst and composeTCvSubst

This patch fixes two distinct (but closely related) buglets that were uncovered
in #22235:

* `liftEnvSubst` used an empty in-scope set, which was not wide enough to cover
  the variables in the range of the substitution. This patch fixes this by
  populating the in-scope set from the free variables in the range of the
  substitution.
* `composeTCvSubst` applied the first substitution argument to the range of the
  second substitution argument, but the first substitution's in-scope set was
  not wide enough to cover the range of the second substutition. We similarly
  fix this issue in this patch by widening the first substitution's in-scope set
  before applying it.

Fixes #22235.

- - - - -
0270cc54 by Vladislav Zavialov at 2022-10-26T00:02:01-04:00
Introduce TcRnWithHsDocContext (#22346)

Before this patch, GHC used withHsDocContext to attach an HsDocContext
to an error message:

	addErr $ mkTcRnUnknownMessage $ mkPlainError noHints (withHsDocContext ctxt msg)

The problem with this approach is that it only works with
TcRnUnknownMessage. But could we attach an HsDocContext to a
structured error message in a generic way? This patch solves
the problem by introducing a new constructor to TcRnMessage:

	data TcRnMessage where
	  ...
	  TcRnWithHsDocContext :: !HsDocContext -> !TcRnMessage -> TcRnMessage
	  ...

- - - - -
ff692cd2 by Simon Peyton Jones at 2022-10-26T11:02:11+01:00
Add missing dict binds to specialiser

I had forgotten to add the auxiliary dict bindings to the
/unfolding/ of a specialised function.  This caused #22358.

I spent 20 mins trying to provoke this error in a small repro
example, but it wasn't easy!  So I'm not adding a regression
test here: the packages
     fixed-vector
     indexed-traversable

will show up if it regresses!

- - - - -


30 changed files:

- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Cmm.hs
- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Cmm/Info/Build.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Make.hs
- compiler/GHC/Core/Opt/ConstantFold.hs
- compiler/GHC/Core/Opt/OccurAnal.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Opt/Stats.hs
- compiler/GHC/Core/Subst.hs
- compiler/GHC/Core/TyCo/Subst.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unfold/Make.hs
- compiler/GHC/Data/FastString.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- compiler/GHC/Hs.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Dump.hs
- compiler/GHC/Hs/Extension.hs
- compiler/GHC/HsToCore/Foreign/C.hs
- compiler/GHC/HsToCore/Pmc/Solver/Types.hs
- compiler/GHC/HsToCore/Quote.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5236875b701352834c0911907a721f281f6c2355...ff692cd20b19871c83dd598205ab7989f74a7dd4

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5236875b701352834c0911907a721f281f6c2355...ff692cd20b19871c83dd598205ab7989f74a7dd4
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/20221026/9bae7400/attachment-0001.html>


More information about the ghc-commits mailing list