January 2014 - ghc-tickets

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 17 Jan '14

17 Jan '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): These allocations are not freed. I don't know Linker.c perfectly yet. From what I saw, I've got am impression there are some other things which are not freed and I've decided to ignore this for a while to be in time for 7.8, because it is too painful to not have working GHC for 64-bit windows (not only we have no repl, we also have no any (indirectly)TH-dependent code i.e. we have virtually nothing nontrivial at all). But thanks for references! I'll look into them and will try to make things better. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 17 Jan '14

17 Jan '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by simonmar): Great work! I wonder whether it might be better to allocate a single space for the trampolines like we do for other platforms (see `ocAllocateSymbolExtras`), rather than a separate allocation for each symbol. Do these allocations ever get freed again? See `freeObjectCode`. Neither of these is a blocker, if this makes GHCi work we should just get it in and make tickets for remaining issues. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 16 Jan '14

16 Jan '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): Also we can now get rid of bigaddr=0 ugly hack for 7.6. HEAD does not contain it anyway. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8670: GHC fails to build on Solaris 11
by GHC 16 Jan '14

16 Jan '14

#8670: GHC fails to build on Solaris 11 -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Keywords: Cabal | Operating System: Solaris Architecture: x86 | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Hello, GHC HEAD fails to build on Solaris 11, the compilation fails in libraries/haskeline with: {{{ "inplace/bin/hsc2hs" '--cc=/usr/bin/gcc' '--ld=/usr/bin/gcc' --cross-safe -I/opt/gmp-5.1.3/include/ --cflag=-U__i686 --cflag=-fno-stack-protector --cflag=-Di386_HOST_ARCH=1 --cflag=-Dsolaris2_HOST_OS=1 --cflag=-D__GLASGOW_HASKELL__=707 '--cflag=-U__i686' '--cflag=-fno-stack- protector' '--cflag=-Ilibraries/haskeline/includes' '-- cflag=-DUSE_GHC_ENCODINGS' '--cflag=-DTERMINFO' '-- cflag=-I/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/directory/include' '--cflag=-I/export/home/karel/vcs/ghc- src/ghc-sol-test/libraries/unix/include' '--cflag=-I/export/home/karel/vcs /ghc-src/ghc-sol-test/libraries/time/include' '-- cflag=-I/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/containers/include' '--cflag=-I/export/home/karel/vcs/ghc- src/ghc-sol-test/libraries/bytestring/include' '-- cflag=-I/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/base/include' '--cflag=-I/opt/gmp-5.1.3/include/' '-- cflag=-I/export/home/karel/vcs/ghc-src/ghc-sol-test/rts/dist/build' '-- cflag=-I/export/home/karel/vcs/ghc-src/ghc-sol-test/includes' '-- cflag=-I/export/home/karel/vcs/ghc-src/ghc-sol-test/includes/dist- derivedconstants/header' '--lflag=-L/export/home/karel/vcs/ghc-src/ghc- sol-test/libraries/transformers/dist-install/build' '-- lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/terminfo /dist-install/build' '--lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/directory/dist-install/build' '-- lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/unix/dist- install/build' '--lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/time/dist-install/build' '--lflag=-L/export/home/karel/vcs /ghc-src/ghc-sol-test/libraries/old-locale/dist-install/build' '-- lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/filepath /dist-install/build' '--lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/containers/dist-install/build' '-- lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/bytestring /dist-install/build' '--lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/deepseq/dist-install/build' '-- lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/array/dist- install/build' '--lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol- test/libraries/base/dist-install/build' '--lflag=-L/export/home/karel/vcs /ghc-src/ghc-sol-test/libraries/integer-gmp/dist-install/build' '-- lflag=-L/opt/gmp-5.1.3/lib/' '--lflag=-L/export/home/karel/vcs/ghc-src /ghc-sol-test/libraries/ghc-prim/dist-install/build' '-- lflag=-L/export/home/karel/vcs/ghc-src/ghc-sol-test/rts/dist/build' '-- lflag=-lcurses' '--lflag=-ldl' '--lflag=-lgmp' '--lflag=-lm' '-- lflag=-lrt' '--lflag=-ldl' --cflag=-Ilibraries/haskeline/dist- install/build/autogen --cflag=-include --cflag=libraries/haskeline/dist- install/build/autogen/cabal_macros.h libraries/haskeline/./System/Console/Haskeline/Backend/Posix.hsc -o libraries/haskeline/dist- install/build/System/Console/Haskeline/Backend/Posix.hs Posix.hsc: In function ‘main’: Posix.hsc:74:5: error: invalid application of ‘sizeof’ to incomplete type ‘struct winsize’ Posix.hsc:76:5: error: ‘TIOCGWINSZ’ undeclared (first use in this function) Posix.hsc:76:5: note: each undeclared identifier is reported only once for each function it appears in Posix.hsc:77:5: error: invalid use of undefined type ‘struct winsize’ Posix.hsc:78:5: error: invalid use of undefined type ‘struct winsize’ compiling libraries/haskeline/dist- install/build/System/Console/Haskeline/Backend/Posix_hsc_make.c failed (exit code 1) command was: /usr/bin/gcc -c libraries/haskeline/dist- install/build/System/Console/Haskeline/Backend/Posix_hsc_make.c -o libraries/haskeline/dist- install/build/System/Console/Haskeline/Backend/Posix_hsc_make.o -I/opt/gmp-5.1.3/include/ -U__i686 -fno-stack-protector -Di386_HOST_ARCH=1 -Dsolaris2_HOST_OS=1 -D__GLASGOW_HASKELL__=707 -U__i686 -fno-stack- protector -Ilibraries/haskeline/includes -DUSE_GHC_ENCODINGS -DTERMINFO -I/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/directory/include -I/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/unix/include -I/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/time/include -I/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/containers/include -I/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/bytestring/include -I/export/home/karel/vcs/ghc-src/ghc-sol-test/libraries/base/include -I/opt/gmp-5.1.3/include/ -I/export/home/karel/vcs/ghc-src/ghc-sol- test/rts/dist/build -I/export/home/karel/vcs/ghc-src/ghc-sol-test/includes -I/export/home/karel/vcs/ghc-src/ghc-sol-test/includes/dist- derivedconstants/header -Ilibraries/haskeline/dist-install/build/autogen -include libraries/haskeline/dist-install/build/autogen/cabal_macros.h -I/export/home/karel/vcs/ghc-src/ghc-sol-test/inplace/lib/include/ gmake[1]: *** [libraries/haskeline/dist- install/build/System/Console/Haskeline/Backend/Posix.hs] Error 1 }}} The reason for this can be tracked to the haskeline.cabal file code: {{{ if os(solaris) { cpp-options: -DUSE_TERMIOS_H } }}} the cpp-options are not modified on Solaris although they should. The reason for this is a bug in Cabal which does not recognize Solaris from its i386-pc-solaris2.11 triple. The bug is reported with suggested patch here: https://github.com/haskell/cabal/issues/1641 The a little extended patch is already in Cabal HEAD and it is promised to be merged into 1.18 branch by Mikhail Glushenkov here: http://www.haskell.org/pipermail/ghc-devs/2014-January/003819.html Now, the question is if it is possible to get the fix into GHC HEAD before 7.8 RC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8670> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 16 Jan '14

16 Jan '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: patch Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Changes (by awson): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:34> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32
by GHC 16 Jan '14

16 Jan '14

#7134: ghc-7.6.0.20120810-x86_64-windows.exe -> internal error R_X86_64_PC32 -------------------------------+---------------------------------- Reporter: cetinsert | Owner: thoughtpolice Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: GHCi | Version: 7.6.1-rc1 Resolution: | Keywords: R_X86_64_PC32 Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------+---------------------------------- Comment (by awson): This patch makes static built win64 GHC 7.6.3 work. I think this patch will apply cleanly to HEAD too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7134#comment:33> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4267: Strictness analyser is to conservative about passing a boxed parameter
by GHC 16 Jan '14

16 Jan '14

#4267: Strictness analyser is to conservative about passing a boxed parameter -------------------------------------+------------------------------------ Reporter: tibbe | Owner: nomeata Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.13 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by simonpj): * owner: => nomeata * difficulty: => Unknown Comment: All versions give good code now, happily! Worth adding a regression test. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4267#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5949: Demand analysis attributes manifestly wrong demand type
by GHC 16 Jan '14

16 Jan '14

#5949: Demand analysis attributes manifestly wrong demand type --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by simonpj): * owner: => nomeata Comment: Seems fixed; Joachim will add a perf test to make sure it stays fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5949#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5949: Demand analysis attributes manifestly wrong demand type
by GHC 16 Jan '14

16 Jan '14

#5949: Demand analysis attributes manifestly wrong demand type --------------------------------------------+------------------------------ Reporter: batterseapower | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Description changed by simonpj: Old description: > (Further to my email to Simon, adding to bug tracker so it doesn't get > lost) > > Consider: > > {{{ > e :: (Int, Int) -> Int -> (Int, Int) > e x y = x `seq` if y > 10 > then x > else e x (y + 1) > }}} > > After worker/wrapper we get: > > {{{ > Rec { > CPR2.$we [Occ=LoopBreaker] > :: (GHC.Types.Int, GHC.Types.Int) > -> GHC.Prim.Int# -> (# GHC.Types.Int, GHC.Types.Int #) > [GblId, > Arity=2, > Caf=NoCafRefs, > Str=DmdType S(AA)L, > Unf=OtherCon []] > CPR2.$we = > \ (w_srv :: (GHC.Types.Int, GHC.Types.Int)) > (ww_srt :: GHC.Prim.Int#) -> > case GHC.Prim.># ww_srt 10 of _ { > GHC.Types.False -> > case GHC.Prim.+# ww_srt 1 of sat_ssS { __DEFAULT -> > CPR2.$we w_srv sat_ssS > }; > GHC.Types.True -> > case w_srv of _ { (ww2_srA, ww3_srB) -> (# ww2_srA, ww3_srB #) } > } > end Rec } > }}} > > The demand type S(AA) is entirely wrong because the box is unused (so it > should be U(AA)) and because the two components are not absent -- they > are used. > > This leads to the worker/wrapper transformation being insufficiently > agressive. This bites in practice with examples like: > > {{{ > d :: M.Map Int Int -> (Int, Int) > d m = M.foldrWithKey' (\k v (a, b) -> if k + v > 2 then (a, b) else > (b, a)) (0, 1) m > }}} > > Which generates this inner loop: > > {{{ > Rec { > CPR2.$wgo2 [Occ=LoopBreaker] > :: (GHC.Types.Int, GHC.Types.Int) > -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int > -> (# GHC.Types.Int, GHC.Types.Int #) > [GblId, > Arity=2, > Caf=NoCafRefs, > Str=DmdType S(AA)S, > Unf=OtherCon []] > CPR2.$wgo2 = > \ (w_srS :: (GHC.Types.Int, GHC.Types.Int)) > (w1_srQ :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) -> > case w1_srQ of _ { > Data.Map.Base.Tip -> > case w_srS of _ { (ww1_srW, ww2_srX) -> (# ww1_srW, ww2_srX #) }; > Data.Map.Base.Bin rb_st1 kx_ss3 x_ssa l_ssk r_ss6 -> > case kx_ss3 of _ { GHC.Types.I# x1_ssd -> > case CPR2.$wgo2 w_srS r_ss6 of _ { (# ww1_ssi, ww2_ssh #) -> > case x_ssa of _ { GHC.Types.I# y_sse -> > case GHC.Prim.+# x1_ssd y_sse of sat_st0 { __DEFAULT -> > case GHC.Prim.># sat_st0 2 of _ { > GHC.Types.False -> > let { > sat_ssZ :: (GHC.Types.Int, GHC.Types.Int) > [LclId] > sat_ssZ = (ww2_ssh, ww1_ssi) } in > CPR2.$wgo2 sat_ssZ l_ssk; > GHC.Types.True -> > let { > sat_st6 :: (GHC.Types.Int, GHC.Types.Int) > [LclId] > sat_st6 = (ww1_ssi, ww2_ssh) } in > CPR2.$wgo2 sat_st6 l_ssk > } > } > } > } > } > } > end Rec } > }}} > > Note that it allocates a pair every go around the loop. If we just ran > the demand analyser on this code again we could eliminate this > allocation, but the demand analyser shouldn't be generating code which > has these manifest problems. > > One way to fix this is to change the ending of dmdTransform to read: > > {{{ > if isTopLevel top_lvl > then fn_ty -- Don't record top level things > else case dmd of > Box (Eval (Poly Abs)) | DmdType _ _ res <- fn_ty, > returnsCPR res -> addVarDmd fn_ty var (Eval (Poly lazyDmd)) > _ > -> addVarDmd fn_ty var dmd > }}} > > But this is a hack. Better suggestions welcome. New description: Consider: {{{ e :: (Int, Int) -> Int -> (Int, Int) e x y = x `seq` if y > 10 then x else e x (y + 1) }}} After worker/wrapper we get: {{{ Rec { CPR2.$we [Occ=LoopBreaker] :: (GHC.Types.Int, GHC.Types.Int) -> GHC.Prim.Int# -> (# GHC.Types.Int, GHC.Types.Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType S(AA)L, Unf=OtherCon []] CPR2.$we = \ (w_srv :: (GHC.Types.Int, GHC.Types.Int)) (ww_srt :: GHC.Prim.Int#) -> case GHC.Prim.># ww_srt 10 of _ { GHC.Types.False -> case GHC.Prim.+# ww_srt 1 of sat_ssS { __DEFAULT -> CPR2.$we w_srv sat_ssS }; GHC.Types.True -> case w_srv of _ { (ww2_srA, ww3_srB) -> (# ww2_srA, ww3_srB #) } } end Rec } }}} The demand type S(AA) is entirely wrong because the box is unused (so it should be U(AA)) and because the two components are not absent -- they are used. This leads to the worker/wrapper transformation being insufficiently agressive. This bites in practice with examples like: {{{ d :: M.Map Int Int -> (Int, Int) d m = M.foldrWithKey' (\k v (a, b) -> if k + v > 2 then (a, b) else (b, a)) (0, 1) m }}} Which generates this inner loop: {{{ Rec { CPR2.$wgo2 [Occ=LoopBreaker] :: (GHC.Types.Int, GHC.Types.Int) -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int -> (# GHC.Types.Int, GHC.Types.Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType S(AA)S, Unf=OtherCon []] CPR2.$wgo2 = \ (w_srS :: (GHC.Types.Int, GHC.Types.Int)) (w1_srQ :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) -> case w1_srQ of _ { Data.Map.Base.Tip -> case w_srS of _ { (ww1_srW, ww2_srX) -> (# ww1_srW, ww2_srX #) }; Data.Map.Base.Bin rb_st1 kx_ss3 x_ssa l_ssk r_ss6 -> case kx_ss3 of _ { GHC.Types.I# x1_ssd -> case CPR2.$wgo2 w_srS r_ss6 of _ { (# ww1_ssi, ww2_ssh #) -> case x_ssa of _ { GHC.Types.I# y_sse -> case GHC.Prim.+# x1_ssd y_sse of sat_st0 { __DEFAULT -> case GHC.Prim.># sat_st0 2 of _ { GHC.Types.False -> let { sat_ssZ :: (GHC.Types.Int, GHC.Types.Int) [LclId] sat_ssZ = (ww2_ssh, ww1_ssi) } in CPR2.$wgo2 sat_ssZ l_ssk; GHC.Types.True -> let { sat_st6 :: (GHC.Types.Int, GHC.Types.Int) [LclId] sat_st6 = (ww1_ssi, ww2_ssh) } in CPR2.$wgo2 sat_st6 l_ssk } } } } } } end Rec } }}} Note that it allocates a pair every go around the loop. If we just ran the demand analyser on this code again we could eliminate this allocation, but the demand analyser shouldn't be generating code which has these manifest problems. One way to fix this is to change the ending of dmdTransform to read: {{{ if isTopLevel top_lvl then fn_ty -- Don't record top level things else case dmd of Box (Eval (Poly Abs)) | DmdType _ _ res <- fn_ty, returnsCPR res -> addVarDmd fn_ty var (Eval (Poly lazyDmd)) _ -> addVarDmd fn_ty var dmd }}} But this is a hack. Better suggestions welcome. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5949#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6070: Fun with the demand analyser
by GHC 16 Jan '14

16 Jan '14

#6070: Fun with the demand analyser -------------------------------------+------------------------------------ Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Description changed by simonpj: Old description: > Max writes: I've been trying to speed up the supercompiler, and in the > process > I've noticed some infelicities in the demand analyser that might be > worth looking at. > > == Infelicity 1: analysis does not take into account extra unboxing done > by the CPR transformation == > An example is: > {{{ > e :: (Int, Int) -> Int -> (Int, Int) > e x y = x `seq` if y > 10 > then x > else e x (y + 1) > }}} > Because x is seqed, the occurrence in the "then" branch gets the CPR > property so e has the CPR property overall. However, the overall > demand on x is S(AA), i.e. the demand analyser believes the x box is > used -- if the box were unused it would get the demand U(LL). So the > overall demand type is S(AA)U(L)m, and the worker looks like: > {{{ > Rec { > CPR2.$we [Occ=LoopBreaker] > :: (GHC.Types.Int, GHC.Types.Int) > -> GHC.Prim.Int# -> (# GHC.Types.Int, GHC.Types.Int #) > [GblId, > Arity=2, > Caf=NoCafRefs, > Str=DmdType S(AA)L, > Unf=OtherCon []] > CPR2.$we = > \ (w_srv :: (GHC.Types.Int, GHC.Types.Int)) > (ww_srt :: GHC.Prim.Int#) -> > case GHC.Prim.># ww_srt 10 of _ { > GHC.Types.False -> > case GHC.Prim.+# ww_srt 1 of sat_ssS { __DEFAULT -> > CPR2.$we w_srv sat_ssS > }; > GHC.Types.True -> > case w_srv of _ { (ww2_srA, ww3_srB) -> (# ww2_srA, ww3_srB #) } > } > end Rec } > }}} > But if we demand-analysed $we then GHC would say that it had the > demand type U(LL)L and unbox the pair argument! It seems silly that > the demand analyser outputs code that can be improved further by just > running demand analysis again. > > Somewhere where this really bit me in practice is in: > {{{ > d :: M.Map Int Int -> (Int, Int) > d m = M.foldrWithKey' (\k v (a, b) -> if k + v > 2 then (a, b) else > (b, a)) (0, 1) m > }}} > Which generates this inner loop: > {{{ > Rec { > CPR2.$wgo2 [Occ=LoopBreaker] > :: (GHC.Types.Int, GHC.Types.Int) > -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int > -> (# GHC.Types.Int, GHC.Types.Int #) > [GblId, > Arity=2, > Caf=NoCafRefs, > Str=DmdType S(AA)S, > Unf=OtherCon []] > CPR2.$wgo2 = > \ (w_srS :: (GHC.Types.Int, GHC.Types.Int)) > (w1_srQ :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) -> > case w1_srQ of _ { > Data.Map.Base.Tip -> > case w_srS of _ { (ww1_srW, ww2_srX) -> (# ww1_srW, ww2_srX #) }; > Data.Map.Base.Bin rb_st1 kx_ss3 x_ssa l_ssk r_ss6 -> > case kx_ss3 of _ { GHC.Types.I# x1_ssd -> > case CPR2.$wgo2 w_srS r_ss6 of _ { (# ww1_ssi, ww2_ssh #) -> > case x_ssa of _ { GHC.Types.I# y_sse -> > case GHC.Prim.+# x1_ssd y_sse of sat_st0 { __DEFAULT -> > case GHC.Prim.># sat_st0 2 of _ { > GHC.Types.False -> > let { > sat_ssZ :: (GHC.Types.Int, GHC.Types.Int) > [LclId] > sat_ssZ = (ww2_ssh, ww1_ssi) } in > CPR2.$wgo2 sat_ssZ l_ssk; > GHC.Types.True -> > let { > sat_st6 :: (GHC.Types.Int, GHC.Types.Int) > [LclId] > sat_st6 = (ww1_ssi, ww2_ssh) } in > CPR2.$wgo2 sat_st6 l_ssk > } > } > } > } > } > } > end Rec } > }}} > We can save a number of allocations proportional to the size of the > Map if the demand analyser didn't have this problem. > > I hacked up the analyser to "fix" this by changing the lines at line > 473 onward to read: > {{{ > if isTopLevel top_lvl > then fn_ty -- Don't record top level things > else case dmd of > Box (Eval (Poly Abs)) | DmdType _ _ res <- fn_ty, > returnsCPR res -> addVarDmd fn_ty var (Eval (Poly lazyDmd)) > _ > -> addVarDmd fn_ty var dmd > }}} > So if we demand a CPRish variable (such as bound by a case scrutinee > or a U(LL)-demanded lambda-binder) in the evalDmd then I throw away > the Box part of the evalDmd on the basis that after CPRing we won't > demand the box at all. > > I doubt this hack is the right solution (and I haven't tried it to see > how it affects the libraries) but perhaps it gives you some ideas. > > == Infelicity 2: a case where demand summarisation hurts us == > > I found practical examples where summarising the demand transfomer of > a function as a single strictness signature hurt us. The examples were > code like: > {{{ > h :: (Int, Int) -> Int -> (Int, Int) > h x y = if y > 10 > then x > else h (case h x 0 of (y1, y2) -> (y2, y1)) (y + 1) > }}} > If, at the innermost use of h, we re-analyse h in the demand > C(C(U(LL))) rather than just unleashing the vanilla DmdSig computed > from the demand C(C(S)) then we can unbox the pair argument. Currently > GHC just gives h the DmdType SU(L) which doesn't eliminate the > allocation of the pair at all. > > This situation occurs in practice with code like: > {{{ > c :: M.Map Int Int -> (Int, Int) > c m = M.foldrWithKey (\k v (a, b) -> if k + v > 2 then (a, b) else (b, > a)) (0, 1) m > }}} > The difference from my earlier example d is that I'm using the version > of `foldrWithKey` that doesn't call `seq`. Current GHC generates this > inner loop: > {{{ > Rec { > CPR2.c_go2 [Occ=LoopBreaker] > :: (GHC.Types.Int, GHC.Types.Int) > -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int > -> (GHC.Types.Int, GHC.Types.Int) > [GblId, > Arity=2, > Caf=NoCafRefs, > Str=DmdType U(L*)S, > Unf=OtherCon []] > CPR2.c_go2 = > \ (z_spW :: (GHC.Types.Int, GHC.Types.Int)) > (ds_spU :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) -> > case ds_spU of _ { > Data.Map.Base.Tip -> z_spW; > Data.Map.Base.Bin rb_sqq kx_sq2 x_sq9 l_sqj r_sq5 -> > case kx_sq2 of _ { GHC.Types.I# x1_sqc -> > case CPR2.c_go2 z_spW r_sq5 of wild2_sqk { (a_sqh, b_sqg) -> > case x_sq9 of _ { GHC.Types.I# y_sqd -> > case GHC.Prim.+# x1_sqc y_sqd of sat_sqp { __DEFAULT -> > case GHC.Prim.># sat_sqp 2 of _ { > GHC.Types.False -> > let { > sat_sqo :: (GHC.Types.Int, GHC.Types.Int) > [LclId] > sat_sqo = (b_sqg, a_sqh) } in > CPR2.c_go2 sat_sqo l_sqj; > GHC.Types.True -> CPR2.c_go2 wild2_sqk l_sqj > } > } > } > } > } > } > end Rec } > }}} > I implemented this but the overhead of reanalysing a function at each > occurrence site is prohibitive (with my changes paraffins took 2.5s to > compile instead of 0.3s). It does fix the problem though. > > A scheme like in "stricterness more relevant" but with let-binding > that is polymorphic in the use-site demand might be able to detect the > extra strictness here. I think Stefan Holdermanns has a paper > describing such a system. But this is anyway much harder to fix than > my first infelicity. New description: Max writes: I've been trying to speed up the supercompiler, and in the process I've noticed some infelicities in the demand analyser that might be worth looking at. One is #5949. The other is: == Infelicity 2: a case where demand summarisation hurts us == I found practical examples where summarising the demand transfomer of a function as a single strictness signature hurt us. The examples were code like: {{{ h :: (Int, Int) -> Int -> (Int, Int) h x y = if y > 10 then x else h (case h x 0 of (y1, y2) -> (y2, y1)) (y + 1) }}} If, at the innermost use of h, we re-analyse h in the demand C(C(U(LL))) rather than just unleashing the vanilla DmdSig computed from the demand C(C(S)) then we can unbox the pair argument. Currently GHC just gives h the DmdType SU(L) which doesn't eliminate the allocation of the pair at all. This situation occurs in practice with code like: {{{ c :: M.Map Int Int -> (Int, Int) c m = M.foldrWithKey (\k v (a, b) -> if k + v > 2 then (a, b) else (b, a)) (0, 1) m }}} The difference from my earlier example d is that I'm using the version of `foldrWithKey` that doesn't call `seq`. Current GHC generates this inner loop: {{{ Rec { CPR2.c_go2 [Occ=LoopBreaker] :: (GHC.Types.Int, GHC.Types.Int) -> Data.Map.Base.Map GHC.Types.Int GHC.Types.Int -> (GHC.Types.Int, GHC.Types.Int) [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType U(L*)S, Unf=OtherCon []] CPR2.c_go2 = \ (z_spW :: (GHC.Types.Int, GHC.Types.Int)) (ds_spU :: Data.Map.Base.Map GHC.Types.Int GHC.Types.Int) -> case ds_spU of _ { Data.Map.Base.Tip -> z_spW; Data.Map.Base.Bin rb_sqq kx_sq2 x_sq9 l_sqj r_sq5 -> case kx_sq2 of _ { GHC.Types.I# x1_sqc -> case CPR2.c_go2 z_spW r_sq5 of wild2_sqk { (a_sqh, b_sqg) -> case x_sq9 of _ { GHC.Types.I# y_sqd -> case GHC.Prim.+# x1_sqc y_sqd of sat_sqp { __DEFAULT -> case GHC.Prim.># sat_sqp 2 of _ { GHC.Types.False -> let { sat_sqo :: (GHC.Types.Int, GHC.Types.Int) [LclId] sat_sqo = (b_sqg, a_sqh) } in CPR2.c_go2 sat_sqo l_sqj; GHC.Types.True -> CPR2.c_go2 wild2_sqk l_sqj } } } } } } end Rec } }}} I implemented this but the overhead of reanalysing a function at each occurrence site is prohibitive (with my changes paraffins took 2.5s to compile instead of 0.3s). It does fix the problem though. A scheme like in "stricterness more relevant" but with let-binding that is polymorphic in the use-site demand might be able to detect the extra strictness here. I think Stefan Holdermanns has a paper describing such a system. But this is anyway much harder to fix than my first infelicity. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6070#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0