- ghc-tickets - Haskell.org

[GHC] #8039: RTS linker: unloadObj() does not actually unload the code
by GHC 05 Jul '13

05 Jul '13

#8039: RTS linker: unloadObj() does not actually unload the code ---------------------------------+------------------------------------------ Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ We've known about this for a long time, but it hasn't been a pressing issue in GHCi. The problem with actually unloading code is that there might be pointers into it from the heap or other RTS data structures, so we need to do a full heap traversal to discover whether it is safe to unload code or not. This is an issue for a project at Facebook that needs to have long running processes that regularly unload and load code using the RTS linker, and right now the process grows over time. This ticket is to track the issue, and I'm also working on a fix. The same problem affects the dynamic linker, although I'm not planning to fix that (yet). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8039> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8033: add AVX register support to llvm calling convention
by GHC 05 Jul '13

05 Jul '13

#8033: add AVX register support to llvm calling convention -----------------------------+---------------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- GHC HEAD currently has support for SSE 128bit registers (XMM), and it would be very little additional work to add 256bit AVX2 operations (when available) PROVIDED that the llvm calling convention for ghc is modified to support them when available the current definition in LLVM can be seen here https://github.com/llvm- mirror/llvm/blob/master/lib/Target/X86/X86CallingConv.td#L279-L291 the current definition is {{{ def CC_X86_64_GHC : CallingConv<[ // Promote i8/i16/i32 arguments to i64. CCIfType<[i8, i16, i32], CCPromoteToType<i64>>, // Pass in STG registers: Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim CCIfType<[i64], CCAssignToReg<[R13, RBP, R12, RBX, R14, RSI, RDI, R8, R9, R15]>>, // Pass in STG registers: F1, F2, F3, F4, D1, D2 CCIfType<[f32, f64, v16i8, v8i16, v4i32, v2i64, v4f32, v2f64], CCIfSubtarget<"hasSSE1()", CCAssignToReg<[XMM1, XMM2, XMM3, XMM4, XMM5, XMM6]>>>, ]>; }}} I believe the update should read {{{ def CC_X86_64_GHC : CallingConv<[ // Promote i8/i16/i32 arguments to i64. CCIfType<[i8, i16, i32], CCPromoteToType<i64>>, // Pass in STG registers: Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim CCIfType<[i64], CCAssignToReg<[R13, RBP, R12, RBX, R14, RSI, RDI, R8, R9, R15]>>, // Pass in STG registers for floats,doubles and 128bit simd vectors CCIfType<[f32, f64, v16i8, v8i16, v4i32, v2i64, v4f32, v2f64], CCIfSubtarget<"hasSSE1()", CCAssignToReg<[XMM1, XMM2, XMM3, XMM4, XMM5, XMM6]>>>, // Pass in STG registers for first 7 256bit simd vectors CCIfType<[v32i8, v16i16, v8i32, v4i64, v8f32, v4f64], CCIfSubtarget<"hasAVX()", CCAssignToReg<[YMM0, YMM1, YMM2, YMM3, YMM4, YMM5, YMM6]>>> ]>; }}} Note that this is FULLY backwards compatible with current GHC, it merely means that we can have 256bit simd values if we so choose. if I get the go ahead from y'all, i'm happy to see about getting that patch into llvm -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8033> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8027: Adding one call to getNumCapabilities triggers performance nose dive (6X slowdown)
by GHC 05 Jul '13

05 Jul '13

#8027: Adding one call to getNumCapabilities triggers performance nose dive (6X slowdown) ------------------------------------+--------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- This is a strange one. I'm in the process of writing an efficient routine for reading large files of decimal/ASCII numbers, in order to make reasonable Haskell versions of the PBBS benchmarks. The following reproducer reads a file and parses the numbers inside it. Simply calling "getNumCapabilities" BEFORE reading the file makes it leap from taking 4.5 seconds to 25-30 seconds: https://github.com/iu- parfunc/lvars/blob/cfb5110eb172b9a9dd10e9863b2f87420d1dadf6/haskell- prototype/Util/PBBS.hs#L30 The file is a standalone reproducer and there's a Makefile in that directory that will build and run it in the bugged and unbugged modes. When you run "make" you should see output as in the following Gist: https://gist.github.com/rrnewton/5901965 ...... time ./unbugged.exe Using parReadNats + readFile Time to read file sequentially: 0.311108s SKIPPING read of num capabilities... Now this is getting ridiculous... Result: 1 segments of output <segment, length 69568627> 4.59 real 3.89 user 0.66 sys time ./bugged.exe Using parReadNats + readFile Time to read file sequentially: 0.342555s Read num capabilities as 1 Now this is getting ridiculous... Result: 1 segments of output <segment, length 69568627> 38.79 real 37.57 user 1.18 sys Currently I'm running it on a 550Mb file containing 69 million numbers. Any file of whitespace-separated positive numbers will do, but if you want the exact file I'm using you can download it here: http://www.cs.indiana.edu/~rrnewton/temp/3Dgrid_J_10000000 Or you can download the PBBS benchmark suite and run the generator to produce that file (http://www.cs.cmu.edu/~pbbs/) Anyway, it should have nothing to do with the file. One thing that is interesting is that calling certain OTHER system functions appears to create the same performance effect as "getNumCapabilities". Namely, getEnvironment and setNumCapabilities cause the problem, but getEnv and writeFile don't. I've attached the Core produced in the bugged and unbugged case to the Gist as well: https://gist.github.com/rrnewton/5901965#file-pbbs_bugged-dump-simpl https://gist.github.com/rrnewton/5901965#file-pbbs_unbugged-dump-simpl Finally, the above numbers are from my mac laptop, GHC 7.6.2. But the problem is exactly the same on the Linux/GHC-7.6.3 machine I tried, and I'm in the process of building a fresh GHC head to check it there... -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8027> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #7574: Register allocator chokes on certain branches with literals
by GHC 05 Jul '13

05 Jul '13

#7574: Register allocator chokes on certain branches with literals -----------------------------+---------------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: 7571, 7573 -----------------------------+---------------------------------------------- While running the test for #7571 (test is in #7573,) under '''WAY=normal''' instead of '''WAY=llvm''', I encountered this bug in the native backend: {{{ =====> T7571(normal) 6 of 6 [0, 0, 0] cd . && '/Users/a/code/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -no-hs-main >T7571.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130113 for x86_64-apple-darwin): allocateRegsAndSpill: Cannot read from uninitialized register %vI_c7 }}} The test in question is: {{{ #include "Cmm.h" testLiteralBranch (W_ dst, W_ src) { if (1) { prim %memcpy(dst, src, 1024, 4); } else { prim %memcpy(dst, src, 512, 8); } return (); } }}} If you comment out the branch conditionals, the test passes, so clearly something fishy is going on here. The test also fails if you change the condition to ```if (1 == 1)``` I have absolutely no idea how this did not trip the profiling-based build in StgStdThunks.cmm, like in the LLVM build c.f. #7571 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7574> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 17

Re: [GHC] #4101: Primitive constant unfolding
by GHC 05 Jul '13

05 Jul '13

#4101: Primitive constant unfolding -------------------------+-------------------------------------------------- Reporter: malosh | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.2 Keywords: | Os: Unknown/Multiple Architecture: x86 | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | -------------------------+-------------------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4101#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2132: Optimise nested comparisons
by GHC 05 Jul '13

05 Jul '13

#2132: Optimise nested comparisons --------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime performance bug | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jan.stolarek@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2132#comment:35> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5567: LLVM: Improve alias analysis / performance
by GHC 05 Jul '13

05 Jul '13

#5567: LLVM: Improve alias analysis / performance ---------------------------------+------------------------------------------ Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (LLVM) | Version: Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: Runtime performance bug Difficulty: | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by jstolarek): * cc: jan.stolarek@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5567#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5212: waitForProcess: does not exist (No child processes)
by GHC 04 Jul '13

04 Jul '13

#5212: waitForProcess: does not exist (No child processes) ------------------------------------------+--------------------------------- Reporter: chrisdone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.4.2 Resolution: | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Incorrect result at runtime | Difficulty: Testcase: | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Changes (by chrisdone): * status: closed => new * cc: chrisdone@… (added) * component: GHC API => Runtime System * version: 6.12.3 => 7.4.2 * owner: chrisdone => * resolution: worksforme => Comment: Oddly, two years later I am experiencing the same problem. I was never able to reproduce it outside of production, which was a machine I had no control over. In the end I worked around it by running: catch (waitForProcess pid >>= return) (\_ -> return $ ExitSuccess) However, that was a workaround, not a solution. This time with a completely different codebase, XMonad, I can reproduce it in few lines of code: Here's a test-case: {{{ import Control.Concurrent import System.Process import XMonad import XMonad.Config main = do forkIO $ xmonad defaultConfig readProcess "ghc" ["--version"] "" >>= putStrLn }}} Compile and run like this (make sure you don't have xmonad already running): {{{ chris@retina:~$ ghc --make X.hs -threaded [1 of 1] Compiling Main ( X.hs, X.o ) Linking X ... chris@retina:~$ ./X X: waitForProcess: does not exist (No child processes) }}} The GHC version is 7.4.2, but it perhaps it's not so much a GHC bug but some behaviour of the runtime system and interaction with exceptions that is subtle or unclear to me. Can anyone reproduce, and if so, why does this happen? If you comment out the forkIO line, the program succeeds. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5212#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8037: GHC panic when compiling unsafeCoerce
by GHC 04 Jul '13

04 Jul '13

#8037: GHC panic when compiling unsafeCoerce ---------------------------+------------------------------------------------ Reporter: ghc@… | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: MacOS X | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: ---------------------------+------------------------------------------------ The GHC compiler crashes on the following program. {{{ module Test where import Unsafe.Coerce import Graphics.Rendering.OpenGL (color, Color3, GLdouble) data D4 = D4 Double Double Double Double crash :: D4 -> IO () crash c = color (invalidCast c) invalidCast :: D4 -> Color3 GLdouble invalidCast = unsafeCoerce }}} With the following output: {{{ [1 of 1] Compiling Test ( Test.hs, Test.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.1 for x86_64-apple-darwin): cgLookupPanic (probably invalid Core; try -dcore-lint) ww_s28U{v} [lid] static binds for: local binds for: }}} I've made several attempts to make the input program smaller, but all modifications will result in successful compilation. The cast is invalid but should produce an runtime error, not a compile time error. Changes I made that somehow prevent this bug from appearing: - Changing the `crash` functions into point free style `color . invalidCast`. - Decreasing the amount of doubles in the `D4` datatype. - Inlining the exact definitions from the OpenGL package. - Using the `print` function instead of the `color` function. (btw, I know I shouldn't use unsafeCoerce) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8038: Old-time is not built when building GHC 7.7.20130704 (perf) for Windows x86_64
by GHC 04 Jul '13

04 Jul '13

#8038: Old-time is not built when building GHC 7.7.20130704 (perf) for Windows x86_64 --------------------------------+------------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: normal | Component: libraries/old-time Version: 7.7 | Keywords: Os: Windows | Architecture: x86_64 (amd64) Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- make install fails with {{{ Installing library in G:/Progs/MSys/local/lib\old-time-1.1.0.1 ghc-cabal.exe: Error: Could not find module: System.Time with any suffix: }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0