[Git][ghc/ghc][wip/win32-m32] 15 commits: [Sized Cmm] properly retain sizes.

Fri Nov 27 23:30:52 UTC 2020

Ben Gamari pushed to branch wip/win32-m32 at Glasgow Haskell Compiler / GHC

Commits:
be5d74ca by Moritz Angermann at 2020-11-26T16:00:32-05:00
[Sized Cmm] properly retain sizes.

This replaces all Word<N> = W<N># Word# and Int<N> = I<N># Int#  with
Word<N> = W<N># Word<N># and Int<N> = I<N># Int<N>#, thus providing us
with properly sized primitives in the codegenerator instead of pretending
they are all full machine words.

This came up when implementing darwinpcs for arm64.  The darwinpcs reqires
us to pack function argugments in excess of registers on the stack.  While
most procedure call standards (pcs) assume arguments are just passed in
8 byte slots; and thus the caller does not know the exact signature to make
the call, darwinpcs requires us to adhere to the prototype, and thus have
the correct sizes.  If we specify CInt in the FFI call, it should correspond
to the C int, and not just be Word sized, when it's only half the size.

This does change the expected output of T16402 but the new result is no
less correct as it eliminates the narrowing (instead of the `and` as was
previously done).

Bumps the array, bytestring, text, and binary submodules.

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

Metric Increase:
    T13701
    T14697

- - - - -
a84e53f9 by Andreas Klebinger at 2020-11-26T16:00:32-05:00
RTS: Fix failed inlining of copy_tag.

On windows using gcc-10 gcc failed to inline copy_tag into evacuate.

To fix this we now set the always_inline attribute for the various
copy* functions in Evac.c. The main motivation here is not the
overhead of the function call, but rather that this allows the code
to "specialize" for the size of the closure we copy which is often
known at compile time.

An earlier commit also tried to avoid evacuate_large inlining. But
didn't quite succeed. So I also marked evacuate_large as noinline.

Fixes #12416

- - - - -
cdbd16f5 by Sylvain Henry at 2020-11-26T16:00:33-05:00
Fix toArgRep to support 64-bit reps on all systems

[This is @Ericson2314 writing a commit message for @hsyl20's patch.]

(Progress towards #11953, #17377, #17375)

`Int64Rep` and `Word64Rep` are currently broken on 64-bit systems.  This
is because they should use "native arg rep" but instead use "large arg
rep" as they do on 32-bit systems, which is either a non-concept or a
128-bit rep depending on one's vantage point.

Now, these reps currently aren't used during 64-bit compilation, so the
brokenness isn't observed, but I don't think that constitutes reasons
not to fix it. Firstly, the linked issues there is a clearly expressed
desire to use explicit-bitwidth constructs in more places. Secondly, per
[1], there are other bugs that *do* manifest from not threading
explicit-bitwidth information all the way through the compilation
pipeline. One can therefore view this as one piece of the larger effort
to do that, improve ergnomics, and squash remaining bugs.

Also, this is needed for !3658. I could just merge this as part of that,
but I'm keen on merging fixes "as they are ready" so the fixes that
aren't ready are isolated and easier to debug.

[1]: https://mail.haskell.org/pipermail/ghc-devs/2020-October/019332.html

- - - - -
a9378e69 by Tim Barnes at 2020-11-26T16:00:34-05:00
Set dynamic users-guide TOC spacing (fixes #18554)

- - - - -
86a59d93 by Ben Gamari at 2020-11-26T16:00:34-05:00
rts: Use RTS_LIKELY in CHECK

Most compilers probably already infer that
`barf` diverges but it nevertheless doesn't
hurt to be explicit.
- - - - -
5757e82b by Matthew Pickering at 2020-11-26T16:00:35-05:00
Remove special case for GHC.ByteCode.Instr

This was added in
https://github.com/nomeata/ghc-heap-view/commit/34935206e51b9c86902481d84d2f368a6fd93423

GHC.ByteCode.Instr.BreakInfo no longer exists so the special case is dead code.

Any check like this can be easily dealt with in client code.

- - - - -
d9c8b5b4 by Matthew Pickering at 2020-11-26T16:00:35-05:00
Split Up getClosureDataFromHeapRep

Motivation

1. Don't enforce the repeated decoding of an info table, when the client
can cache it (ghc-debug)
2. Allow the constructor information decoding to be overridden, this
casues segfaults in ghc-debug

- - - - -
3e3555cc by Andreas Klebinger at 2020-11-26T16:00:35-05:00
RegAlloc: Add missing raPlatformfield to RegAllocStatsSpill

Fixes #18994

Co-Author: Benjamin Maurer <maurer.benjamin at gmail.com>

- - - - -
a1a75aa9 by Ben Gamari at 2020-11-27T06:20:41-05:00
rts: Allocate MBlocks with MAP_TOP_DOWN on Windows

As noted in #18991, we would previously allocate heap in low memory.
Due to this the linker, which typically *needs* low memory, would end up
competing with the heap. In longer builds we end up running out of
low memory entirely, leading to linking failures.

- - - - -
396fe39e by Ben Gamari at 2020-11-27T18:30:42-05:00
rts/m32: Refactor handling of allocator seeding

Previously, in an attempt to reduce fragmentation, each new allocator
would map a region of M32_MAX_PAGES fresh pages to seed itself. However,
this ends up being extremely wasteful since it turns out that we often
use fewer than this.  Consequently, these pages end up getting freed
which, ends up fragmenting our address space more than than we would
have if we had naively allocated pages on-demand.

Here we refactor m32 to avoid this waste while achieving the
fragmentation mitigation previously desired. In particular, we move all
page allocation into the global m32_alloc_page, which will pull a page
from the free page pool. If the free page pool is empty we then refill
it by allocating a region of M32_MAP_PAGES and adding them to the pool.

Furthermore, we do away with the initial seeding entirely. That is, the
allocator starts with no active pages: pages are rather allocated on an
as-needed basis.

On the whole this ends up being a pleasingly simple change,
simultaneously making m32 more efficient, more robust, and simpler.

Fixes #18980.

- - - - -
30b4668b by Ben Gamari at 2020-11-27T18:30:42-05:00
rts: Introduce mmapAnonForLinker

Previously most of the uses of mmapForLinker were mapping anonymous
memory, resulting in a great deal of unnecessary repetition. Factor this
out into a new helper.

Also fixes a few places where error checking was missing or suboptimal.

- - - - -
1e5a25a8 by Ben Gamari at 2020-11-27T18:30:42-05:00
rts/linker: Introduce munmapForLinker

Consolidates munmap calls to ensure consistent error handling.

- - - - -
99f82448 by Ben Gamari at 2020-11-27T18:30:42-05:00
rts/Linker: Introduce Windows implementations for mmapForLinker, et al.

- - - - -
0782380e by Ben Gamari at 2020-11-27T18:30:42-05:00
rts/m32: Introduce NEEDS_M32 macro

Instead of relying on RTS_LINKER_USE_MMAP

- - - - -
b70fa768 by Ben Gamari at 2020-11-27T18:30:42-05:00
rts/linker: Use m32 to allocate symbol extras in PEi386

- - - - -

30 changed files:

- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/ByteCode/Asm.hs
- compiler/GHC/Cmm.hs
- compiler/GHC/Cmm/Expr.hs
- compiler/GHC/CmmToAsm/Ppr.hs
- compiler/GHC/CmmToAsm/Reg/Graph.hs
- compiler/GHC/CmmToAsm/Reg/Graph/Stats.hs
- compiler/GHC/CmmToC.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Opt/ConstantFold.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/CoreToByteCode.hs
- compiler/GHC/HsToCore/Foreign/Call.hs
- compiler/GHC/HsToCore/Foreign/Decl.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/Runtime/Heap/Inspect.hs
- compiler/GHC/Stg/Lift/Analysis.hs
- compiler/GHC/StgToCmm/ArgRep.hs
- compiler/GHC/StgToCmm/DataCon.hs
- compiler/GHC/StgToCmm/Layout.hs
- compiler/GHC/StgToCmm/Prim.hs
- compiler/GHC/StgToCmm/Ticky.hs
- compiler/GHC/StgToCmm/Utils.hs
- compiler/GHC/Types/Literal.hs
- compiler/GHC/Utils/Outputable.hs
- docs/users_guide/conf.py
- ghc/ghc-bin.cabal.in
- includes/Rts.h

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f6c843a8da43748f0365fbac1b73c80883b64499...b70fa768dfcf58cbd67e9e2224791be1839c6945

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f6c843a8da43748f0365fbac1b73c80883b64499...b70fa768dfcf58cbd67e9e2224791be1839c6945
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/20201127/18cf5b81/attachment.html>