[Git][ghc/ghc][wip/local-symbols-2] 12 commits: Don't use non-portable operator "==" in configure.ac

Ben Gamari gitlab at gitlab.haskell.org
Wed Mar 18 19:55:34 UTC 2020



Ben Gamari pushed to branch wip/local-symbols-2 at Glasgow Haskell Compiler / GHC


Commits:
e1aa4052 by PHO at 2020-03-17T11:36:09Z
Don't use non-portable operator "==" in configure.ac

The test operator "==" is a Bash extension and produces a wrong result
if /bin/sh is not Bash.

- - - - -
89f034dd by Maximilian Tagher at 2020-03-17T11:36:48Z
Document the units of -ddump-timings

Right now, in the output of -ddump-timings to a file, you can't tell what the units are:

```
CodeGen [TemplateTestImports]: alloc=22454880 time=14.597
```

I believe bytes/milliseconds are the correct units, but confirmation would be appreciated. I'm basing it off of this snippet from `withTiming'`:

```
when (verbosity dflags >= 2 && prtimings == PrintTimings)
  $ liftIO $ logInfo dflags (defaultUserStyle dflags)
      (text "!!!" <+> what <> colon <+> text "finished in"
       <+> doublePrec 2 time
       <+> text "milliseconds"
       <> comma
       <+> text "allocated"
       <+> doublePrec 3 (realToFrac alloc / 1024 / 1024)
       <+> text "megabytes")
```

which implies time is in milliseconds, and allocations in bytes (which divided by 1024 would be KB, and again would be MB)

- - - - -
beffa147 by Simon Peyton Jones at 2020-03-17T11:37:25Z
Implement mapTyCo like foldTyCo

This patch makes mapType use the successful idiom described
in TyCoRep
   Note [Specialising foldType]

I have not yet changed any functions to use mapType, though there
may be some suitable candidates.

This patch should be a no-op in terms of functionality but,
because it inlines the mapper itself, I'm hoping that there may
be some modest perf improvements.

Metric Decrease:
    T5631
    T5642
    T3064
    T9020
    T14683
    hie002
    haddock.Cabal
    haddock.base
    haddock.compiler

- - - - -
5800ebfe by Ömer Sinan Ağacan at 2020-03-17T11:38:08Z
Don't update ModDetails with CafInfos when opts are disabled

This is consistent with the interface file behavior where we omit
HsNoCafRefs annotations with -fomit-interface-pragmas (implied by -O0).

ModDetails and ModIface are just different representations of the same
thing, so they really need to be in sync. This patch does the right
thing and does not need too much explanation, but here's an example of a
problem not doing this causes in !2842:

    -- MyInteger.hs
    module MyInteger
      ( MyInteger (MyInteger)
      , ToMyInteger (toMyInteger)
      ) where

    newtype MyInteger = MyInteger Integer

    class ToMyInteger a where
      toMyInteger :: a -> MyInteger

    instance ToMyInteger Integer where
      toMyInteger = MyInteger {- . succ -}

    -- Main.hs
    module Main
      ( main
      ) where

    import MyInteger (MyInteger (MyInteger), toMyInteger)

    main :: IO ()
    main = do
      let (MyInteger i) = (id . toMyInteger) (41 :: Integer)
      print i

If I build this with -O0, without this fix, we generate a ModDetails with
accurate LFInfo for toMyInteger (MyInteger.$fToMyIntegerInteger) which says that
it's a LFReEntrant with arity 1. This means in the use site (Main) we tag the
value:

    R3 = MyInteger.$fToMyIntegerInteger_closure + 1;
    R2 = GHC.Base.id_closure;
    R1 = GHC.Base.._closure;
    Sp = Sp - 16;
    call stg_ap_ppp_fast(R4, R3, R2, R1) args: 24, res: 0, upd: 24;

Now we change the definition by uncommenting the `succ` part and it becomes a thunk:

    MyInteger.$fToMyIntegerInteger [InlPrag=INLINE (sat-args=0)]
      :: MyInteger.ToMyInteger GHC.Integer.Type.Integer
    [GblId[DFunId(nt)]] =
        {} \u [] $ctoMyInteger_rEA;

and its LFInfo is now LFThunk. This change in LFInfo makes a difference in the
use site: we can no longer tag it.

But becuase the interface fingerprint does not change (because ModIface does not
change) we don't rebuild Main and tag the thunk.

(1.2% increase in allocations when building T12545 on armv7 because we
generate more code without CafInfos)

Metric Increase:
    T12545

- - - - -
5b632dad by Paavo at 2020-03-17T11:38:48Z
Add example for Data.Semigroup.diff

- - - - -
4d85d68b by Paavo at 2020-03-17T11:38:48Z
Clean up

- - - - -
75168d07 by Paavo at 2020-03-17T11:38:48Z
Make example collapsible

- - - - -
53ff2cd0 by Richard Eisenberg at 2020-03-17T13:46:57Z
Fix #17021 by checking more return kinds

All the details are in new Note [Datatype return kinds] in
TcTyClsDecls.

Test case: typecheck/should_fail/T17021{,b}
           typecheck/should_compile/T17021a

Updates haddock submodule

- - - - -
528df8ec by Sylvain Henry at 2020-03-18T14:06:43Z
Modules: Core operations (#13009)

- - - - -
4e8a71c1 by Richard Eisenberg at 2020-03-18T14:07:19Z
Add release note about fix to #16502.

We thought we needed to update the manual, but the fix for #16502
actually brings the implementation in line with the manual. So we
just alert users of how to update their code.

- - - - -
50bef0e9 by Ben Gamari at 2020-03-18T19:44:09Z
codeGen: Produce local symbols for module-internal functions

It turns out that some important native debugging/profiling tools (e.g.
perf) rely only on symbol tables for function name resolution (as
opposed to using DWARF DIEs). However, previously GHC would emit
temporary symbols (e.g. `.La42b`) to identify module-internal
entities. Such symbols are dropped during linking and therefore not
visible to runtime tools (in addition to having rather un-helpful unique
names). For instance, `perf report` would often end up attributing all
cost to the libc `frame_dummy` symbol since Haskell code was no covered
by any proper symbol (see #17605).

We now rather follow the model of C compilers and emit
descriptively-named local symbols for module internal things. Since this
will increase object file size this behavior can be disabled with the
`-fno-expose-all-symbols` flag.

With this `perf record` can finally be used against Haskell executables.
Even more, with `-g3` `perf annotate` provides inline source code.

- - - - -
da78b1dc by Ben Gamari at 2020-03-18T19:54:35Z
Enable -fexpose-all-symbols when debug level is set

- - - - -


30 changed files:

- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/Monad.hs
- compiler/GHC/CmmToAsm/PPC/Ppr.hs
- compiler/GHC/CmmToAsm/SPARC/Ppr.hs
- compiler/GHC/CmmToAsm/X86/Ppr.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion/Axiom.hs
- compiler/GHC/Core/FamInstEnv.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Make.hs
- compiler/simplCore/CSE.hs → compiler/GHC/Core/Op/CSE.hs
- compiler/simplCore/CallArity.hs → compiler/GHC/Core/Op/CallArity.hs
- compiler/prelude/PrelRules.hs → compiler/GHC/Core/Op/ConstantFold.hs
- compiler/stranal/CprAnal.hs → compiler/GHC/Core/Op/CprAnal.hs
- compiler/stranal/DmdAnal.hs → compiler/GHC/Core/Op/DmdAnal.hs
- compiler/simplCore/Exitify.hs → compiler/GHC/Core/Op/Exitify.hs
- compiler/simplCore/FloatIn.hs → compiler/GHC/Core/Op/FloatIn.hs
- compiler/simplCore/FloatOut.hs → compiler/GHC/Core/Op/FloatOut.hs
- compiler/simplCore/LiberateCase.hs → compiler/GHC/Core/Op/LiberateCase.hs
- compiler/simplCore/CoreMonad.hs → compiler/GHC/Core/Op/Monad.hs
- compiler/simplCore/CoreMonad.hs-boot → compiler/GHC/Core/Op/Monad.hs-boot
- compiler/simplCore/OccurAnal.hs → compiler/GHC/Core/Op/OccurAnal.hs
- compiler/simplCore/SetLevels.hs → compiler/GHC/Core/Op/SetLevels.hs
- compiler/simplCore/Simplify.hs → compiler/GHC/Core/Op/Simplify.hs
- compiler/simplCore/SimplCore.hs → compiler/GHC/Core/Op/Simplify/Driver.hs
- compiler/simplCore/SimplEnv.hs → compiler/GHC/Core/Op/Simplify/Env.hs
- compiler/simplCore/SimplMonad.hs → compiler/GHC/Core/Op/Simplify/Monad.hs
- compiler/simplCore/SimplUtils.hs → compiler/GHC/Core/Op/Simplify/Utils.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/d7ccbf461ae92a197f17bdbb489b33f08c9b4fc8...da78b1dc317c22ee4f7da77a20a30c0f54d3e2fe

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/d7ccbf461ae92a197f17bdbb489b33f08c9b4fc8...da78b1dc317c22ee4f7da77a20a30c0f54d3e2fe
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/20200318/a2d26581/attachment.html>


More information about the ghc-commits mailing list