November 2013 - ghc-tickets

[GHC] #8156: amd64 + in-tree gmp build broken
by GHC 23 Jan '17

23 Jan '17

#8156: amd64 + in-tree gmp build broken -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: #4022 #4366 #4374 | -------------------------------------+------------------------------------- Currently, the GHC build system has an in-tree GMP. This GMP seems to be used only if there is no usable GMP found on the system and the user didn't provide one using configure flags. When we build GHC using an external shared version of GMP, the resulting GHC is dynamically linked against GMP and also the generated programs are linked dynamically against GMP. When the in-tree GMP is used, it is built statically, even if the GHC we are building is shared GHC on GNU/Linux. This feature is currently broken on amd64 (#4366, #4022), but is working currently very well on Linux i686. Apart from the breakage this setting is very flexible and I'd be very happy if it were possible to keep it, in spite of removeal requests like #4374. When there is a system GMP, nothing would change, this is the most typical usage, e.g. distributions are all building this way. On the other hand, if the user removes his GMP (maybe we should provide an option to explicity trigger this in ./configure, instead of having to remove GMP); she can build a GHC that is not linked dynamically against GMP and the resulting programs are not linked either. This makes it possible to generate binaries that link dynamically against libc (no -static) which is quite compatible amongst versions, but doesn't require a libgmp.so to run. For binary deployments this seems to be the best kind of setup nowadays. Now, if we were only able to fix this for amd64. See this: https://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3 On amd64 we can continue to compile GMP statically and link into the binary library, we just have to compile GMP with the fPIC. I attached the patch to fix this. Previously a similar patch has been rejected in #4022 because "this shouldn't be platform specific", but this is clearly not the case, this is specific to amd64. Tadaaaam: {{{ errge@sid64:~/ghc/inplace/bin$ cat test.hs main = print (2^100) errge@sid64:~/ghc/inplace/bin$ ./ghc-stage2 test.hs [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... errge@sid64:~/ghc/inplace/bin$ ./test 1267650600228229401496703205376 errge@sid64:~/ghc/inplace/bin$ ldd ./test linux-vdso.so.1 (0x00007fff79962000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe4b9a83000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe4b987a000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe4b9676000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe4b92c6000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe4b90a6000) /lib64/ld-linux-x86-64.so.2 (0x00007fe4b9d83000) }}} No GMP! I attach the build file patch to the bugreport. So, can we please apply this patch and just keep the in-tree GMP? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8156> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8107: need types to express constant argument for primop correctness
by GHC 22 Dec '16

22 Dec '16

#8107: need types to express constant argument for primop correctness ------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- (not sure if this is a bug or a feature request, or a task, or a dialogue, filing as a bug for now) a number of compiler intrinsics that GHC has started to support (prefetch) and will come to support (concurrent memory operations a la http://ghc.haskell.org/trac/ghc/ticket/7883) require certain arguments to be statically fixed at compile time {{{ primop PrefetchAddrOp "prefetchAddr#" GenPrimOp Addr# -> Int# -> Addr# with llvm_only = True }}} consider the specification on the llvm side for prefetch http://llvm.org/docs/LangRef.html#llvm-prefetch-intrinsic {{{ Syntax:¶ declare void @llvm.prefetch(i8* <address>, i32 <rw>, i32 <locality>, i32 <cache type>) Overview: The ‘llvm.prefetch‘ intrinsic is a hint to the code generator to insert a prefetch instruction if supported; otherwise, it is a noop. Prefetches have no effect on the behavior of the program but can change its performance characteristics. Arguments: address is the address to be prefetched, rw is the specifier determining if the fetch should be for a read (0) or write (1), and locality is a temporal locality specifier ranging from (0) - no locality, to (3) - extremely local keep in cache. The cache type specifies whether the prefetch is performed on the data (1) or instruction (0) cache. The rw, locality and cache type arguments must be constant integers. }}} the punch line is that we're starting add primops that REALLY require certain arguments to be compile time constants to work correctly, otherwise there will by definition be compiler errors after the c-- phase when operations are passed along to the llvm backend and friends. (for the atomicity ops, i'll be looking into adding them to the native code gen, but the point being it will likely trigger an error at code gen time). a strawman approach would look like adding a type {{{ ReallyActuallyConstant :: * or unliftedtype -> * unliftedtype}}} roughly, then prefetch could have the type {{{ primop PrefetchAddrOp "prefetchAddr#" GenPrimOp Addr# ->ReallyActuallyConstant Int# -> Addr# with llvm_only = True }}} a way of emulating something like this functionality now, would be some template haskell that lets you lift a compile time constant of type t into the type ReallyActuallyConstant t, and is the only way to build a value of that type "ReallyActuallyConstant t". That said, that approach seems like a bad way of providing type safetype for making sure primops actually compile! Point being, some sort of way of nicely enforcing that a value needs to be available at compile time, that doesn't require doing abusing template haskell, is the idea i'm pointing at. Might also be useful for other things, but for now, i'm merely remarking on an invariant these primops have -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8107> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size)
by GHC 16 Dec '16

16 Dec '16

#8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size) ----------------------------------------------+---------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: 8287 ----------------------------------------------+---------------------------- currently GHC's internals and code gen don't provide a strong distinction between Ints as data, and Ints for pointer / address arithmetic. This also comes up as being problematical in a number of ways. 1. We wind up having many portability issues around Int and pointer / address sizes. 2. adds some inessential complexity / problems to adding new architectures to ghc. eg x32 ABI which has 32bit pointers and 64bit ints somewhat breaks current assumptions in the GHC primops (because arrays are indexed by a byte offset, and the valid range for those is determined by the ABI pointer size!) 3. this Ints and Ptrs confusion we currently have, also means we can't leverage the Integer support in SIMD registers that is in most modern CPUs! If we could have those two separated better, theres a lot of low leve optimizations we could do for Int/Word data that we currently cant do! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8299> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8248: GHCi should not warn if group writable
by GHC 13 Dec '16

13 Dec '16

#8248: GHCi should not warn if group writable ----------------------------+---------------------------------------------- Reporter: afcowie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects valid program Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Any number of Linux distros support the idea of user groups, whereby when a new user is created there is also simultaneously a group created with the same name; ie, instead of {{{ -rw-r--r--. 1 andrew users 19 Sep 5 08:29 ghci.conf }}} as us old traditionalists would have it, you get {{{ -rw-rw-r--. 1 andrew andrew 19 Sep 5 08:29 ghci.conf }}} because the umask in such cases is 0002 instead of 0022. There is entirely nothing unusual or incorrect about this approach, and it is followed, for example, in the Fedora family of distros. GHC, however, is being a bit silly in emitting the following: {{{ $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. *** WARNING: /home/andrew/.ghc/ghci.conf is writable by someone else, IGNORING! Prelude> }}} Foremost the fact that the file is group writable is not a problem and the user's choice, //particularly// in this case because it's group writable in the user's group! Regardless of that, GHCi should not be ignoring files with other than 0644 permissions; this isn't `.ssh/`. Can this check and attendant behaviour be removed? AfC -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8248> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8460: Annotation reification with types in TH
by GHC 07 Dec '16

07 Dec '16

#8460: Annotation reification with types in TH -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: #8397 | Test Case: | Blocking: -------------------------------------------+------------------------------- The attached patch adds two simple helper functions to support typed reification of annotations. This was not in the original #8397 patch only because the typed branch was not merged at that time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8460> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8224: Excessive system time -- new IO manager problem?
by GHC 07 Dec '16

07 Dec '16

#8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: IO Manager, | Operating System: Linux System Time | Type of failure: Runtime Architecture: x86_64 (amd64) | performance bug Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- This is an issue that came to light when testing the patches on #910. You can see some of the numbers there. Basically, recent GHC HEAD builds, running a large number of threads blocked on MVars will result in burning a lot of system time. The attached file provides a mediocre reproducer. With it, you can see that building with HEAD as of Aug 31st and running with `-RTS -N32` will result in around 200ms system time, whereas GHC 7.6.3 spends about 30ms in system time. This shows the disparity, but the result is not that egregious. A more noticeable example is on ticket #910, where when running on 31 threads, there is an 8 minutes of system time for 17 minutes of user time, and yet at one thread that system time drops to under two seconds! {{{ 1 thread: real 1m20.028s user 1m17.921s sys 0m1.768s 31 threads: real 1m27.445s user 17m0.314s sys 8m0.175s }}} It needs to be determined whether this system time is a result of the parallel compilation patches on #910, or whether it is a new problem with the runtime system, and in particular with the parallel IO manager. I am inclined to believe that compiling in parallel involves extra IO (repeatedly reading interface files?), but not eight minutes of it!! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #8300: split-objs doesn't split on LLVM
by GHC 22 Nov '16

22 Nov '16

#8300: split-objs doesn't split on LLVM ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- `-split-objs` is allowed with `-fllvm`, but it doesn't really do anything. E.g. in my perf-llvm build I have a `libHSbase-4.7.0.0.a` with `Applicative__1.o`, `Arrow__1.o` etc. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8300> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8321: improve basic block layout on LLVM backend by predicting stack/heap checks
by GHC 17 Nov '16

17 Nov '16

#8321: improve basic block layout on LLVM backend by predicting stack/heap checks ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (LLVM) | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Currently we don't give the LLVM optimizer any information about which branch of an `if` is likely to be taken. As a result, the optimizer is likely to produce a basic block layout which is not optimal. Improving the layout can improve performance through better instruction cache usage and better branch prediction by the hardware. We can control LLVM's idea of what is likely with the `llvm.expect` intrinsic function. Some obvious branches which we can predict accurately are the stack and heap checks that appear near the entry of many functions. Here's a small example of some Cmm code and the output of the LLVM optimizer/compiler. {{{ block_c2Lc_entry() // [R1, R2] { info_tbl: [(c2Lc, label: block_c2Lc_info rep:StackRep [])] stack_info: arg_space: 0 updfr_space: Nothing } {offset c2Lc: Hp = Hp + 24; if (Hp > HpLim) goto c2Lm; else goto c2Ll; c2Lm: HpAlloc = 24; R2 = R2; R1 = R1; call stg_gc_pp(R2, R1) args: 8, res: 8, upd: 24; c2Ll: I64[Hp - 16] = :_con_info; P64[Hp - 8] = R1; P64[Hp] = R2; R1 = Hp - 14; Sp = Sp + 8; call (P64[Sp])(R1) args: 24, res: 0, upd: 24; } }] }}} {{{ 00000000000002b8 <c2Lc_info>: 2b8: 4c 89 e0 mov %r12,%rax 2bb: 4c 8d 60 18 lea 0x18(%rax),%r12 2bf: 4d 3b a5 18 01 00 00 cmp 0x118(%r13),%r12 2c6: 76 10 jbe 2d8 <c2Lc_info+0x20> 2c8: 49 c7 85 48 01 00 00 movq $0x18,0x148(%r13) 2cf: 18 00 00 00 2d3: e9 00 00 00 00 jmpq 2d8 <c2Lc_info+0x20> 2d4: R_X86_64_PC32 stg_gc_pp+0xfffffffffffffffc 2d8: 48 c7 40 08 00 00 00 movq $0x0,0x8(%rax) 2df: 00 2dc: R_X86_64_32S ghczmprim_GHCziTypes_ZC_con_info 2e0: 48 89 58 10 mov %rbx,0x10(%rax) 2e4: 4c 89 70 18 mov %r14,0x18(%rax) 2e8: 48 8b 45 08 mov 0x8(%rbp),%rax 2ec: 48 83 c5 08 add $0x8,%rbp 2f0: 49 8d 5c 24 f2 lea -0xe(%r12),%rbx 2f5: ff e0 jmpq *%rax 2f7: 90 nop }}} It would likely be better to invert the branch at `2c6` to a `ja`, so that the common case is adjacent to the function entry, and when `llvm.expect` is used on the condition in the branch, the LLVM optimizer does produce this alternate layout. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8321> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8523: blowup in space/time for type checking and object size for high arity tuples
by GHC 24 Sep '16

24 Sep '16

#8523: blowup in space/time for type checking and object size for high arity tuples -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Eric Mertens found a compilation performance issue in how GHC handles type class instance methods with many equality constraints and large arity tuples. basically using equality constraints to force 62 variables equal, instead of using the same variable for all the tuple slots, make the type checking time go from 0.9 seconds and very little memory to ~20 seconds and ~ 700mb of ram, along with going from ~ 7,000 coercions to 700,000-400,000 coercions, and object file size of 143kb to an object file size of 2.8mb-3.1mb I'm attaching 2 variants Tuple.hs and NeighborTuple.hs that exhibit the blowup behavior, and MonoTuple.hs (better named PolyTuple.hs but thats a side detail) that doesn't exhibit the blow up behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8523> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining
by GHC 04 Aug '16

04 Aug '16

#8099: Alternate syntax for indicating when a function is "fully applied" for purposes of inlining ------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I just remembered an old idea I put to the GHC user's list [http://www .mail-archive.com/glasgow-haskell-users(a)haskell.org/msg22119.html here], and thought I should present it here. As I understand it GHC inlines inlines only after a function is fully applied with respect to the syntactic left-hand side, so in order to control inlining and sharing, we sometimes see strange things like: {{{ {-# INLINE foo #-} foo :: a -> b -> c foo a = \b -> ... }}} It would be nice to be able to define the function syntactically in the way that's the most clear (e.g. in pointfree style, etc.) and specify at what point to inline something like this: {{{ foo :: a -> {-# INLINE #-} b -> c foo a b = ... -- or: foo = ... }}} ...which tells the compiler to inline after applying the arguments to the left of the pragma, and GHC would do whatever trivial (I assume?) eta- conversion was required. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8099> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18