January 2017 - ghc-tickets

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 11 Jan '17

11 Jan '17

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13100: Instability in 8.0.2 on 32-bit Windows
by GHC 11 Jan '17

11 Jan '17

#13100: Instability in 8.0.2 on 32-bit Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The 32-bit Windows build usually segfaults when building Haddock. A bisection reveals, {{{ $ git bisect log git bisect start # good: [4986837f8168cacf95c24fecc84d7b36c47f3c11] rules/build-prog: Ensure programs depend upon their transitive deps git bisect good 4986837f8168cacf95c24fecc84d7b36c47f3c11 # bad: [fb0f4cf66f3fc7590821e6688440bf86c25aced1] Install toplevel handler inside fork. git bisect bad fb0f4cf66f3fc7590821e6688440bf86c25aced1 # good: [2086d86674324c0f5f21e23acbe26f4517843f57] Fix Windows build after Ticky changes git bisect good 2086d86674324c0f5f21e23acbe26f4517843f57 # good: [8f8f0b62ec106b0d503240c4cb7510a7cb4ddbb6] Fix Windows build after Ticky changes git bisect good 8f8f0b62ec106b0d503240c4cb7510a7cb4ddbb6 # good: [b688f0056a1694bb0db3ca2b84ab5505ba9947d7] Fix handling of package-db entries in .ghc.environment files, etc. git bisect good b688f0056a1694bb0db3ca2b84ab5505ba9947d7 # good: [b688f0056a1694bb0db3ca2b84ab5505ba9947d7] Fix handling of package-db entries in .ghc.environment files, etc. git bisect good b688f0056a1694bb0db3ca2b84ab5505ba9947d7 # good: [c904258319b8eb6e47ba727c667bca765537802b] runghc: use executeFile to run ghc process on POSIX git bisect good c904258319b8eb6e47ba727c667bca765537802b # good: [c904258319b8eb6e47ba727c667bca765537802b] runghc: use executeFile to run ghc process on POSIX git bisect good c904258319b8eb6e47ba727c667bca765537802b # good: [28c62bb588f7026d9985afe235cbeec5e3fd9a76] Fix Trac #12797: approximateWC git bisect good 28c62bb588f7026d9985afe235cbeec5e3fd9a76 # bad: [6bee8644d959ec77745d835c8c4453f2147bd8d7] rts: Fix build when linked with gold git bisect bad 6bee8644d959ec77745d835c8c4453f2147bd8d7 # good: [60c299a2278c351abed1ea51a1c2ee5459033fa9] Pass --no-pie to GCC git bisect good 60c299a2278c351abed1ea51a1c2ee5459033fa9 # bad: [cca8ceec97d6b8b031dec837825b97609dd7288f] Read parentheses better git bisect bad cca8ceec97d6b8b031dec837825b97609dd7288f # bad: [fefe02c0324a25a52455a61f7f6e48be6d82d1ab] Pass -no-pie to GCC git bisect bad fefe02c0324a25a52455a61f7f6e48be6d82d1ab # good: [3da461d9ddc8ff6fe14ee9572b617d8e3753de2e] Revert "Pass --no-pie to GCC" git bisect good 3da461d9ddc8ff6fe14ee9572b617d8e3753de2e # first bad commit: [fefe02c0324a25a52455a61f7f6e48be6d82d1ab] Pass -no- pie to GCC }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #12972: Missed specialisation opportunity with phantom type class parameter?
by GHC 11 Jan '17

11 Jan '17

#12972: Missed specialisation opportunity with phantom type class parameter? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am unsure of my analysis of this code fragment. It seems like we could do a better job optimising `test3`. First the code, then the analysis at the bottom. {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE RoleAnnotations #-} {-# LANGUAGE IncoherentInstances #-} module Foo where data Proxy a = Proxy --type role Phantom phantom nominal class Phantom x a | a -> x where method :: a method1 :: a instance Phantom x (Proxy x) where method = Proxy method1 = Proxy -- This doesn't optimise test3 :: Phantom x (Proxy x) => Proxy x test3 = method -- This does optimise instance Phantom Char Int where method = 5 method1 = 5 test4 :: Phantom x Int => Int test4 = method }}} Here is the relevant part of the core {{{#!hs -- RHS size: {terms: 4, types: 9, coercions: 0} test3 test3 = \ @ x_ayL $dPhantom_ayS -> method $dPhantom_ayS -- RHS size: {terms: 3, types: 5, coercions: 0} test4 test4 = \ @ x_ayz _ -> $cmethod1_az4 }}} In `test4` the dictionary selector `method` is eliminated but in the analogous case `test3` where `x` is used in both arguments then `method` is not specialised. It seems that we could do a similar specialisation and ultimately replace the dictionary with `Proxy` as `x` is phantom. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12972> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10262: Improve documentation of module signatures
by GHC 11 Jan '17

11 Jan '17

#10262: Improve documentation of module signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.11 Documentation | Operating System: Unknown/Multiple Keywords: backpack | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Out of curiosity, I read the bit in the user manual about the new module signatures, and I find the text a little confusing. Could those in the know clarify the points below in the manual? Thanks! * (typo) The first example refers to `String.hs`. I think you mean `Text.hs`. * Is there a way to use module signatures to deal with mutually recursive modules? The example with `TextSig` seems to require that both `Text` and `TextSig` are compiled before `A`. * Could you provide an example of specifying multiple signature/implementation pairs with `--make`? * The manual says that the dialect of Haskell used in signature files is "essentially" the same as with hs-boot files. Are there any differences? * The most recent paragraph addition doesn't make sense to me, starting with "Signatures can be installed like ordinary modules". What do you mean by "installed"? What does it mean to bring multiple signatures into scope by the same name? Can two signatures have the same name? Wouldn't their filenames also need to be the same? * Is there currently any facility available to have multiple implementations of one signature? Of course, this is all work in progress, and I don't necessarily expect an immediate fix. But, when it's nearing completion, it may be worth revisiting this stretch of text. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10262> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13066: Backpack doesn't check for fixity consistency
by GHC 11 Jan '17

11 Jan '17

#13066: Backpack doesn't check for fixity consistency -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This should fail, but instead it prints 7. {{{ unit p where signature A where infixl 6 `mul` infixl 7 `plu` mul :: Int -> Int -> Int plu :: Int -> Int -> Int module P where import A x = 2 `mul` 3 `plu` 1 unit i where module A where infixl 7 `mul` infixl 6 `plu` mul :: Int -> Int -> Int mul x y = x * y plu :: Int -> Int -> Int plu x y = x + y unit main where dependency p[A=i:A] module Main where import P main = print x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13066> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13073: BooleanFormula implies is wrong
by GHC 11 Jan '17

11 Jan '17

#13073: BooleanFormula implies is wrong -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The current implementation looks like this: {{{ implies :: Eq a => BooleanFormula a -> BooleanFormula a -> Bool x `implies` Var y = x `impliesAtom` y x `implies` And ys = all (implies x . unLoc) ys x `implies` Or ys = any (implies x . unLoc) ys x `implies` Parens y = x `implies` (unLoc y) }}} This cannot possibly be correct: this will decompose the formula A \/ B -> A \/ B in the following way {{{ Or [Var a, Var b] `implies` Or [Var a, Var b] Or [Var a, Var b] `implies` Var a || Or [Var a, Var b] `implies` Var b }}} But neither of the decomposed formulas are true. I didn't find a case in the typechecker where this actually mattered. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13073> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13041: Type classes in Backpack signatures are dodgy
by GHC 11 Jan '17

11 Jan '17

#13041: Type classes in Backpack signatures are dodgy -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment, we allow exactly the same type class declarations in hsig files as we do in hs-boot files, and matching requires the type class definitions to match up exactly. But this is quite questionable. First, this means that I can't write this in a signature: {{{ class K a where f :: a -> Bool }}} but then implement K with a type class that provides a default. The matching code will say these are not compatible. That's not so useful. Second, it means that I can WRITE a default implementation in a signature file. That seems like a step too far: there are many things I might like to write in a specification of a type class, but what the default methods are seems like a step too far. So it seems we need to fix two things: 1. Relax matching so that you can add defaults post-facto in the implementation of the type class 2. Make hsig more restrictive w.r.t. what class definitions it will accept. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13041> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12994: Module and export level signature thinning in Backpack
by GHC 11 Jan '17

11 Jan '17

#12994: Module and export level signature thinning in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- **The problem.** We want to write signature packages to allow us to reuse signatures, but Backpack in its current incarnation forces us to depend on ALL of the signatures from the signature package. This is troublesome if we only really needed a subset of the signatures from the package. What we'd like is a way to "thin" out the signatures, keeping only the ones we need. In the original design of Backpack, this was not allowed, because if a signature was requiring a function so that a module from that package could use it, you're not permitted to just drop that requirement (someone really needs it!) But signature packages: packages that consist of only signatures (no modules) do not have any such requirement. So let's allow module and export level signature thinning here. **Design.** First, during the course of mix-in linking we infer if a package is a signature package or not. A package is a signature package if it does not have any modules, and itself depends only on fully instantiated packages or signature packages. A signature package is eligible for requirement thinning. A signature package can be thinned at the module level using the `signature-mixins` field, by saying `include-signatures: sig-pkg (A)` (we don't reuse `mixins` field to distinguish signature packages from regular indefinite packages); this means that we only are bringing the signature `A` into scope. If `A` imports another signature `B`, the user is obligated to also bring that signature into scope (if they do not, we will error, although this can only be done by GHC.) By default, all signatures in scope at a name get merged to a name. We add a pragma for controlling what declarations from packages get merged in: {{{ signature A where {-# MERGE "sig-pkg" (T, S, foo, bar, baz) #-} data T qux :: T -> T }}} This line means, "merge in the declarations T, foo, bar, baz from the signature in sig-pkg." Two things to note: 1. If `foo :: S`, you're obligated to also declare `S` in the import list, even if you are not otherwise using it. The reason for this is to make it always explicit what is going to be required in the end. 2. Even if `T` is in the merge list, you still have to declare it locally if you want to make use of it. These are not imports! (:TODO: There is no provision for disambiguating between two signatures from the same package, but mix-linked differently. This seems like a pretty rare case.) The semantics is that we proceed as we do now, but when merging, we apply the explicit import list to reduce the set of entities we actually typecheck and merge in (checking, however, to ensure that these are all well-formed.) That's it, I think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12994> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7102: Type family instance overlap accepted in ghci
by GHC 11 Jan '17

11 Jan '17

#7102: Type family instance overlap accepted in ghci -------------------------------------+------------------------------------- Reporter: exbb2 | Owner: rwbarton Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.4.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => rwbarton -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7102#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop...
by GHC 11 Jan '17

11 Jan '17

#12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- '''Background:''' I've been intrigued investigating whether GHC can produce code "as fast as Cee (C/C++/Rust/etc.)" by-any-means-possible, and have been using the very tight inner composite culling loops (purely integer operations) of a basic Sieve of Eratosthenes implementation as a test vehicle. '''Synopsis:''' This is a follow-on of the work leading to finding the efficiency problem described in ticket #12798, but involves pushing the speed even further as per the method described for "primesieve as per [http://primesieve.org/] in the "Highly optimized inner loop" section. '''Description of test code:''' Essentially, this method involves extreme loop unrolling with very imperative code although coded functionally; in the case of the following code it means that, recognizing that for all odd primes (which they all are other than two), and that all word sizes are of an even number of bits, there will be a repeating pattern of composite number culls that repeats every word size number of bits. Thus for a word size of one eight-bit byte, we can unroll to eight composite culls in the body of one loop, with loops cases for the primes modulo 8 of 1, 3, 5, and 7, and for the eight bit start positions (b0..b7) meaning there are four times eight is 32 loop cases. When there are no longer a full eight culls left, the culling reverts to conventional single-cull-per-loop as per the test program of ticket #12798. To do this using GHC we need pointer arithmetic, and the only way to implement pointer arithmetic in GHC is to use the Addr# primitive. GHC/Haskell has one other slight overhead over Cee languages in that we need to move the culling array to a pinned array to avoid having it moved while the culling is going on and then move it back when finished but this takes a negligible amount of time (one percent or so) as compared to the culling. As usual for test programs, the culling operations are repeated in a loop for a number of times to give more accurate timing not influenced by execution not related to the culling. All of this is included in the following code (truncated as to loop coses for inclusion here): {{{#!hs -- EfficiencyBug.hs -- showing that there is a register loop invariant bug in generation of assembler code... -- LLVM shows the bug clearer since the code is generally a little faster... {-# LANGUAGE FlexibleContexts, BangPatterns, MagicHash, UnboxedTuples #-} {-# OPTIONS_GHC -O2 -rtsopts -keep-s-files #-} -- or -O2 -fllvm import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base import GHC.ST ( ST(..) ) import GHC.Exts numLOOPS = 10000 :: Int -- Uses a very simple Sieve of Eratosthenes for fixed 2 ^ 18 range (so one L1 cache size) to prove it. twos :: UArray Int Word32 twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] soep1 :: () -> [Word32] soep1() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfBts = (256 * 1024) `div` 2 -- to 2^18 + 2 is 128 KBits = 16 KBytes bf <- newArray (0, bfBts - 1) False :: ST s (STUArray s Int Bool) cullb bf cullb bf@(STUArray l u n marr#) = ST $ \s0# -> case getSizeofMutableByteArray# marr# s0# of { (# s1#, n# #) -> let loop t mr# s0# = -- cull a number of times to test timing if t <= 0 then (# s0#, STUArray l u n mr# #) else case getSizeofMutableByteArray# mr# s0# of { (# s1#, n# #) -> case newPinnedByteArray# n# s1# of { (# s2#, marr'# #) -> case copyMutableByteArray# mr# 0# marr'# 0# n# s2# of { s3# -> case unsafeFreezeByteArray# marr'# s3# of { (# s4#, arr# #) -> -- must do this case byteArrayContents# arr# of { adr# -> -- to obtain the addr# here let cullp i@(I# i#) sp# = let !p@(I# p#) = i + i + 3 in let !s@(I# s#) = (p * p - 3) `div` 2 in if s >= n then case copyMutableByteArray# marr'# 0# mr# 0# n# sp# of so# -> (# so#, mr# #) else let !(UArray _ _ _ tarr#) = twos in case readWord64Array# marr# (i# `uncheckedIShiftRL#` 6#) sp# of { (# sp0#, v0# #) -> case (v0# `and#` ((int2Word# 1#) `uncheckedShiftL#` (i# `andI#` 63#))) `eqWord#` (int2Word# 0#) of 0# -> cullp (i + 1) sp0# -- not prime _ -> -- is prime -- most program execution time spent in the following tight loops. -- the following code implments extream loop unrolling... let !pi@(I# pi#) = fromIntegral p in let !sw@(I# sw#) = s `shiftR` 3 in let !sb@(I# sb#) = s .&. 7 in let p1 = sb + pi in let !(I# r1#) = p1 `shiftR` 3 in let p2 = p1 + pi in let !(I# r2#) = p2 `shiftR` 3 in let p3 = p2 + pi in let !(I# r3#) = p3 `shiftR` 3 in let p4 = p3 + pi in let !(I# r4#) = p4 `shiftR` 3 in let p5 = p4 + pi in let !(I# r5#) = p5 `shiftR` 3 in let p6 = p5 + pi in let !(I# r6#) = p6 `shiftR` 3 in let p7 = p6 + pi in let !(I# r7#) = p7 `shiftR` 3 in let !lmt@(I# lmt#) = (fromIntegral n `shiftR` 3) - p7 in let !lmt1# = plusAddr# adr# lmt# in let !strt# = plusAddr# adr# sw# in let !(I# n#) = n in let (# !so#, !sco# #) = case ((((p - 1) `div` 2) .&. 3) `shiftL` 3) + sb of { 0 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 1#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 2#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 4#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 8#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 16#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 32#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 64#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 128#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; 1 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 2#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 4#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 8#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 16#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 32#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 64#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 128#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 1#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; -- and so on for 30 more cases... _ -> (# strt#, sp0# #) {- normally never taken case, all cases covered -} } in let !ns# = ((minusAddr# so# adr#) `uncheckedIShiftL#` 3#) +# sb# in -- extreme loop unrolling ends here; remaining primes culled conventionally... let cull j# sc# = -- very tight inner loop case j# <# n# of 0# -> cullp (i + 1) sc# _ -> let i# = j# `andI#` 31# in let !sh# = indexWord32Array# tarr# i# in -- (1 `shiftL` (j .&. 31))) let w# = j# `uncheckedIShiftRL#` 5# in case readWord32Array# marr'# w# sc# of { (# sc0#, ov# #) -> case writeWord32Array# marr'# w# (ov# `or#` sh#) sc0# of { sc1# -> cull (j# +# pi#) sc1# }} in cull ns# sp0# } in case cullp 0 s4# of (# sp#, mrp# #) -> loop (t - 1) mrp# sp# }}}}} in loop numLOOPS marr# s1# } main = print $ length $ soep1() }}} '''The problem:''' The problem is in the innermost loop of the cases, for which case "0" the following assembly code (using -fllvm) is produced: {{{ seGU_info$def: # BB#0: # %cgRL cmpq %r14, 70(%rbx) jbe .LBB35_1 .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax addq %r14, %rax orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) cmpq 70(%rbx), %rax movq %rax, %r14 jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx rex64 jmpq *%rcx # TAILCALL }}} One can readily see that the compiler is not lifting the Loop Invariant Code Flow as in initializing the registers to outside the inner loop, meaning there are many register loads from memory which are not necessary. '''Desired results:''' The desired assembly code is something like the following, which is similar to what is produced by Cee (C/C++/Rust/etc.): {{{ seGU_info$def: # BB#0: # %cgRL movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax movq 70(%rbx), %rbx cmpq %r14, %rbx jbe .LBB35_1 .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) addq %rax, %r14 cmpq %rbx, %rax jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx # rbx clobbered here anyway rex64 jmpq *%rcx # TAILCALL }}} '''Full testing:''' The actual unrolled loop code is too long to post here, but to verify the result is correct (23000) and the performance, the full actual file is attached here. Due to the magic of modern CPU instruction fusion, the code is not as slow as it would indicate by the number of increased instructions, but while it is about twice as fast as when culled conventionally (Intel Skylake), it is about half again as slow as Cee. On an Intel Sky Lake i5-6500 (running at 3.5 GHz for single threading), this takes about one second, about two seconds culled conventionally, but only about 0.6 seconds for Rust/LLVM (with the assembly code output essentially identical to the "desired" code). '''Other back ends and targets:''' Although the code generated by the native NCG has other problems (not moving the loop test to the end of the loop to avoid one jump, and not combining the read and modify and store instructions into the single available instruction), it exhibits the same problem as to not lifting the Loop Invariant Code Flow register initialization. Although this code is x86_64, the problem also applies to x86 code even though the x86 architecture doesn't have enough registers to do this in one loop and needs to be split into two loops culling only four composites per loop, but there still is a significant gain in speed. Although not tested, it probably also applies to other targets such as ARM (which has many general purpose registers). '''Conclusion:''' The use of Addr# primitives is probably not a frequent use case, but as shown here that when one needs their use, they should be efficient. I considered that GHC may intentionally limit the performance of these unsafe primitives to limit their use unless absolutely necessary as in marshalling, something as C## does for the use of unsafe pointers, but surely GHC would not do that as the target programmers are different. '''If this and ticket #12798 were fixed, for this use case the GHC code would be within a percent or two of the performance of Cee.''' -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12808> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21