[Git][ghc/ghc][wip/int64-everywhere] 11 commits: Fix toArgRep to support 64-bit reps on all systems

[John Ericson]

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


Commits:
b45de34e by Sylvain Henry at 2020-11-22T22:49:08+00: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

- - - - -
0ddb14aa by John Ericson at 2020-11-22T23:35:09+00:00
Merge branch 'wip/fix-64-toArgRep' into HEAD

- - - - -
b110ae65 by John Ericson at 2020-11-23T03:47:10+00:00
Cleanup some primop-related identifers

 - 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.

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

- - - - -
0db851a1 by John Ericson at 2020-11-23T03:49:25+00:00
Merge branch 'wip/primop-naming-consistency' into HEAD

- - - - -
6d78b1e4 by John Ericson at 2020-11-23T03:50:42+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>

- - - - -
fee6ccad by John Ericson at 2020-11-23T03:50:43+00:00
Inline INT64 and WORD64 macros in primops.txt.pp

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

- - - - -
42d3a399 by Sylvain Henry at 2020-11-23T03:50:43+00:00
Adapt rules from #16402 to Word64#/Int64#

- - - - -
a31eecdc by John Ericson at 2020-11-23T03:50:43+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.

- - - - -
2f6e77a2 by John Ericson at 2020-11-23T03:50:43+00:00
`integerFromInt64#` can be inlined when the word size is >= 64 bits

Maybe this will help with the renaming test failure?

- - - - -
09f595f5 by John Ericson at 2020-11-23T03:50:43+00:00
Add builtin rule for `divInt64#` and `modInt64#`

- - - - -
08fa3166 by Sylvain Henry at 2020-11-23T03:50:43+00:00
Fix Word64/Int64 constant-folding

I've refactored literal narrow/coerce functions to make them more
generic. Hence this patch incidentally implements basic support for
Int8/16/32 and Word8/16/32 in Core.

- - - - -


30 changed files:

- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/bytearray-ops.txt.pp
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/ByteCode/Asm.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/CmmToAsm/PPC/CodeGen.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/CoreToByteCode.hs
- compiler/GHC/HsToCore/Match/Literal.hs
- compiler/GHC/Iface/Tidy/StaticPtrTable.hs
- compiler/GHC/Platform.hs
- compiler/GHC/Stg/Lift/Analysis.hs
- compiler/GHC/StgToCmm/ArgRep.hs
- compiler/GHC/StgToCmm/Layout.hs
- compiler/GHC/StgToCmm/Prim.hs
- compiler/GHC/StgToCmm/Ticky.hs
- compiler/GHC/Tc/Deriv/Generate.hs
- compiler/GHC/Tc/Instance/Typeable.hs
- compiler/GHC/Types/Literal.hs
- compiler/GHC/Utils/Outputable.hs
- includes/stg/Prim.h
- libraries/base/GHC/Exts.hs
- libraries/base/GHC/Float.hs
- libraries/base/GHC/Float/ConversionUtils.hs
- libraries/base/GHC/Float/RealFracMethods.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/982ce06332c3a80a7b8d2d4de661f3912fe72a09...08fa3166686dd830fcaf91d9324272c519187797

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/982ce06332c3a80a7b8d2d4de661f3912fe72a09...08fa3166686dd830fcaf91d9324272c519187797
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/20201122/75e3e313/attachment.html>