[Git][ghc/ghc][wip/int64-everywhere] 17 commits: Hadrian: fix detection of ghc-pkg for cross-compilers

Sun Nov 29 02:17:43 UTC 2020

John Ericson pushed to branch wip/int64-everywhere at Glasgow Haskell Compiler / GHC

Commits:
75fc1ed5 by Sylvain Henry at 2020-11-28T15:40:23-05:00
Hadrian: fix detection of ghc-pkg for cross-compilers

- - - - -
7cb5df96 by Sylvain Henry at 2020-11-28T15:40:23-05:00
hadrian: fix ghc-pkg uses (#17601)

Make sure ghc-pkg doesn't read the compiler "settings" file by passing
--no-user-package-db.

- - - - -
e3fd4226 by Ben Gamari at 2020-11-28T15:40:23-05:00
gitlab-ci: Introduce a nightly cross-compilation job

This adds a job to test cross-compilation from x86-64 to AArch64 with
Hadrian.

Fixes #18234

- - - - -
698d3d96 by Ben Gamari at 2020-11-28T15:41:00-05:00
gitlab-ci: Only deploy GitLab Pages in ghc/ghc>

The deployments are quite large and yet are currently only served for
the ghc/ghc> project.

- - - - -
625726f9 by David Eichmann at 2020-11-28T15:41:37-05:00
ghc-heap: partial TSO/STACK decoding

Co-authored-by: Sven Tennie <sven.tennie at gmail.com>
Co-authored-by: Matthew Pickering <matthewtpickering at gmail.com>
Co-authored-by: Ben Gamari <bgamari.foss at gmail.com>

- - - - -
22ea9c29 by Andreas Klebinger at 2020-11-28T15:42:13-05:00
Small optimization to CmmSink.

Inside `regsUsedIn` we can avoid some thunks by specializing the
recursion. In particular we avoid the thunk for `(f e z)` in the
MachOp/Load branches, where we know this will evaluate to z.

Reduces allocations for T3294 by ~1%.

- - - - -
bba42c62 by John Ericson at 2020-11-28T15:42:49-05:00
Make primop handler indentation more consistent

- - - - -
c82bc8e9 by John Ericson at 2020-11-28T15:42:49-05:00
Cleanup some primop constructor names

Harmonize the internal (big sum type) names of the native vs fixed-sized
number primops a bit. (Mainly by renaming the former.)

No user-facing names are changed.

- - - - -
ae14f160 by Ben Gamari at 2020-11-28T15:43:25-05:00
testsuite: Mark T14702 as fragile on Windows

Due to #18953.

- - - - -
d891d942 by John Ericson at 2020-11-28T23:48:23+00:00
Cleanup number primop conversion names

Don't use "extend" or "narrow" in some of the user-facing primops
names for conversions.

  - Names like `narrowInt32#` are misleading when `Int` is 32-bits.

  - Names like `extendInt64#` are flat-out wrong when `Int is
    32-bits.

  - `narrow{Int,Word}<N>#` however map a type to itself, and so don't
    suffer from this problem. They are left as-is.

- - - - -
4d6a5a08 by Sylvain Henry at 2020-11-28T23:50:24+00:00
Make proper fixed-with number literals

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

Besides being nicer to use, this also will allow for better constant
folding for the fixed-width types, on par with what `Int#` and `Word#`
have today.

- - - - -
7aaba66d by John Ericson at 2020-11-28T23:50:24+00:00
Make fixed-size `Int32#` and `Int64#`

The boxed Int64 uses Int64#, but Int32# still uses Int#. The 32-bit case
is less pressing to change because it is not a source of brittle
CPP---it is the same thing on all platforms.

We need Int64/Word64 constant folding to avoid the let/app restriction on Core, so
that is implemented now. 32-bit constant unfolding and 32-bit literals
are left as follow-up.

This is the bulk of #11953

Co-authored-by: Sylvain Henry <hsyl20 at gmail.com>

- - - - -
7b485b79 by John Ericson at 2020-11-28T23:50:24+00:00
Inline INT64 and WORD64 macros in primops.txt.pp

The definition is now unconditional so there is no reason for that CPP.

- - - - -
043b3f3d by Sylvain Henry at 2020-11-28T23:50:24+00:00
Adapt rules from #16402 to Word64#/Int64#

- - - - -
b0c80603 by John Ericson at 2020-11-28T23:50:24+00:00
Copy enumFrom* implementations from Int/Word for Int64/Word64

Without this, we don't get proper list fusion.

I think this sort of copying is OK for now, but we absolutely need
something better if we are going to make `IntN` use `IntN#` for all `N`.
The degree to which proper metaprogramming has been punted upon by
factoring everything through the native-sized types is disconcerting.

- - - - -
54559349 by John Ericson at 2020-11-28T23:50:24+00:00
`integerFromInt64#` can be inlined when the word size is >= 64 bits

Maybe this will help with the renaming test failure?

- - - - -
7135eb06 by John Ericson at 2020-11-28T23:50:24+00:00
Add builtin rule for `divInt64#` and `modInt64#`

- - - - -

30 changed files:

- .gitlab-ci.yml
- .gitlab/ci.sh
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/bytearray-ops.txt.pp
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/ByteCode/Types.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Sink.hs
- compiler/GHC/CmmToAsm/PPC/CodeGen.hs
- compiler/GHC/CmmToAsm/Ppr.hs
- compiler/GHC/CmmToAsm/SPARC/CodeGen.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/CmmToC.hs
- compiler/GHC/CmmToLlvm/CodeGen.hs
- compiler/GHC/Core/Opt/ConstantFold.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/HsToCore/Match/Literal.hs
- compiler/GHC/Iface/Tidy/StaticPtrTable.hs
- compiler/GHC/Platform.hs
- compiler/GHC/Runtime/Interpreter.hs
- compiler/GHC/StgToCmm/Prim.hs
- compiler/GHC/Tc/Deriv/Generate.hs
- compiler/GHC/Tc/Instance/Typeable.hs
- compiler/GHC/Types/Literal.hs
- compiler/GHC/Utils/Outputable.hs
- hadrian/src/Hadrian/Oracles/Cabal/Rules.hs
- hadrian/src/Settings/Builders/GhcPkg.hs
- includes/stg/Prim.h
- libraries/array
- libraries/base/GHC/Exts.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/56a2ac3d302a5c6f949264877e999f2789efecc8...7135eb06cf3e45edc85bffe299b7d0890aded7d1

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/56a2ac3d302a5c6f949264877e999f2789efecc8...7135eb06cf3e45edc85bffe299b7d0890aded7d1
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/20201128/1033ac3d/attachment-0001.html>