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

Mon Nov 23 15:35:34 UTC 2020

John Ericson pushed to branch wip/int64-everywhere-new-float-primops 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

- - - - -
f004001e by Sylvain Henry at 2020-11-23T15:21:42+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.

- - - - -
9428b9c9 by John Ericson at 2020-11-23T15:30:14+00:00
Merge branch 'wip/fixed-width-lits' into HEAD

- - - - -
1b901384 by John Ericson at 2020-11-23T15:30:18+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>

- - - - -
e3041c56 by John Ericson at 2020-11-23T15:30:18+00:00
Inline INT64 and WORD64 macros in primops.txt.pp

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

- - - - -
0055dfb7 by Sylvain Henry at 2020-11-23T15:30:18+00:00
Adapt rules from #16402 to Word64#/Int64#

- - - - -
844eb6c1 by John Ericson at 2020-11-23T15:30:18+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.

- - - - -
46b9e1be by John Ericson at 2020-11-23T15:30:18+00:00
`integerFromInt64#` can be inlined when the word size is >= 64 bits

Maybe this will help with the renaming test failure?

- - - - -
beba0c1e by John Ericson at 2020-11-23T15:30:18+00:00
Add builtin rule for `divInt64#` and `modInt64#`

- - - - -
8569aa12 by John Ericson at 2020-11-23T15:35:30+00:00
WIP: Add missing floats <-> int/word 64 rule and primops

- - - - -

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

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/939e062466af51340a37d814142d5ceb1b4659bf...8569aa12c9e2b2c014f0096f1e52641aecebb159

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/939e062466af51340a37d814142d5ceb1b4659bf...8569aa12c9e2b2c014f0096f1e52641aecebb159
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/d7582fc5/attachment.html>