[Git][ghc/ghc][wip/int64-everywhere] 9 commits: Cleanup some primop-related identifers

[John Ericson]

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


Commits:
58a37f8b by John Ericson at 2020-11-23T04:50:12+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.

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

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

- - - - -
cfb672c4 by Sylvain Henry at 2020-11-23T15:37:10+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.

- - - - -
b08dae07 by John Ericson at 2020-11-23T15:38:21+00:00
Merge branch 'wip/fix-64-toArgRep' into HEAD

- - - - -
f69fc06b by John Ericson at 2020-11-23T15:38:22+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>

- - - - -
1719e501 by John Ericson at 2020-11-23T15:38:22+00:00
Inline INT64 and WORD64 macros in primops.txt.pp

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

- - - - -
f3d65cc0 by Sylvain Henry at 2020-11-23T15:38:22+00:00
Adapt rules from #16402 to Word64#/Int64#

- - - - -
fee83bad by John Ericson at 2020-11-23T15:38:22+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.

- - - - -
c28f1dd8 by John Ericson at 2020-11-23T15:38:22+00:00
`integerFromInt64#` can be inlined when the word size is >= 64 bits

Maybe this will help with the renaming test failure?

- - - - -
7e057ab9 by John Ericson at 2020-11-23T15:38:22+00:00
Add builtin rule for `divInt64#` and `modInt64#`

- - - - -


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/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
- 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
- libraries/base/GHC/Int.hs
- libraries/base/GHC/Integer.hs
- libraries/base/GHC/StaticPtr.hs
- libraries/base/GHC/Word.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/beba0c1e4a7a6a9547e5d110172dbf1403a5e0ac...7e057ab98551b7f49e0d336700c3312a74f90610

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/beba0c1e4a7a6a9547e5d110172dbf1403a5e0ac...7e057ab98551b7f49e0d336700c3312a74f90610
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/20201123/554f9fb7/attachment.html>