June 2018 - ghc-tickets

[GHC] Batch modify: #13072, #13078, #13090, #13091, #13092, #13093, ...
by GHC 21 Jun '18

21 Jun '18

Batch modification to #13072, #13078, #13090, #13091, #13092, #13093, #13152, #13153, #13154, #13176, #13189, #13225, #13226, #13243, #13253, #13309, #13331, #13346, #13357, #13360, #13363, #13390, #13406, #13423, #13448, #13465, #13507, #13511, #13513, #13515, #13554, #13564, #13617, #13629, #13647, #13686, #13692, #13693, #13717, #13753 by bgamari: milestone to 8.8.1 Comment: These will not be addressed in GHC 8.6. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=13072%2C13078%2C13090%2C13091%2C13…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13724: Clamping of llvm llc to -O1 and -O2
by GHC 21 Jun '18

21 Jun '18

#13724: Clamping of llvm llc to -O1 and -O2 -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.3 (LLVM) | 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: -------------------------------------+------------------------------------- We currently clamp the optimization level of llvm llc (3.9 and 4.0) within `[1,2]`. The reason is that with `-O0`, the naive register allocator can topple over with {{{ Error while trying to spill R1 from class GPR: Cannot scavenge register without an emergency spill slot! }}} and with `-O3` the `llvm::SelectionDAGISel::LowerArguments` may break, when compiling `rts/HeapStackCheck.cmm` with the stage1 ghc. {{{ 0 llc 0x0000000102ae63e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40 1 llc 0x0000000102ae69a6 SignalHandler(int) + 358 2 libsystem_platform.dylib 0x00007fffc23f4b3a _sigtramp + 26 3 libsystem_c.dylib 0x00007fffc226498b __vfprintf + 17876 4 llc 0x00000001029d5123 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) + 5699 5 llc 0x0000000102a21a35 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3381 6 llc 0x0000000102a202b1 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1457 7 llc 0x0000000101bdc474 (anonymous namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 20 8 llc 0x00000001025573a6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 134 9 llc 0x000000010274fb12 llvm::FPPassManager::runOnFunction(llvm::Function&) + 498 10 llc 0x000000010274fd23 llvm::FPPassManager::runOnModule(llvm::Module&) + 67 11 llc 0x00000001027501b8 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 920 12 llc 0x000000010195f075 compileModule(char**, llvm::LLVMContext&) + 12133 13 llc 0x000000010195bf0b main + 491 14 libdyld.dylib 0x00007fffc21e5235 start + 1 Stack dump: 0. Program arguments: llc -O3 -mtriple=arm-unknown-linux-gnueabihf -enable-tbaa /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc -o /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_7.lm_s 1. Running pass 'Function Pass Manager' on module '/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc'. 2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"' }}} `opt` and `llc` should respect `-opt_lo` and `-opt_lc`, such that `-opt_lc=-O3` can be used to validate the behaviour. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13724> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] Batch modify: #13072, #13078, #13090, #13091, #13092, #13093, ...
by GHC 21 Jun '18

21 Jun '18

Batch modification to #13072, #13078, #13090, #13091, #13092, #13093, #13152, #13153, #13154, #13176, #13189, #13225, #13226, #13243, #13253, #13309, #13331, #13346, #13357, #13360, #13363, #13390, #13406 by bgamari: milestone to 8.6.1 Comment: This will not be addressed in GHC 8.6. -- Tickets URL: <http://ghc.haskell.org/trac/ghc/query?id=13072%2C13078%2C13090%2C13091%2C13…> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14413: Profiling breaks determinism
by GHC 21 Jun '18

21 Jun '18

#14413: Profiling breaks determinism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Keywords: determinism | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While looking at #5889 I noticed that `CostCentre` currently includes a `Unique` (although it's represented as an `Int` for reasons that aren't relevant here; I change this in Phab:D4148). This unique identifies the cost centre and appears to be derived from the unique of a binder. This presumably breaks determinism. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14413> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13240: Make it easier to find builds we may want to cancel
by GHC 21 Jun '18

21 Jun '18

#13240: Make it easier to find builds we may want to cancel -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: mpickering Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Trac & Git | 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'd love to have a relatively easy way to hunt down and abort Harbormaster builds that aren't very useful, and perhaps to avoid some obviously wasteful builds. Examples: 1. Someone pushed several versions of a single differential, and it seems clear that only the most recent version is likely to be of interest. 2. A build for a different architecture/OS has failed for a reason that seems obviously non-platform-specific. 3. Only documentation files have changed. Building these on one platform should be sufficient. 4. A differential was closed by a commit. Only the most recent build will be useful, if that. It would also be nice to get a list of build jobs waiting for specific platforms. These days, for example, we seem to have a lot more demand than supply for OSX bots. If we could get a list of all pending OSX builds, we could look through them by hand and see if any should be canceled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13240> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13205: Run `validate --slow` during CI at least sometimes.
by GHC 21 Jun '18

21 Jun '18

#13205: Run `validate --slow` during CI at least sometimes. -------------------------------------+------------------------------------- Reporter: dobenour | 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: -------------------------------------+------------------------------------- We really should run `validate --slow` at times. It would catch #13204. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13205> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10059: :i doesn't work for ~
by GHC 21 Jun '18

21 Jun '18

#10059: :i doesn't work for ~ -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs Prelude> :set -XTypeOperators Prelude> :i (~) <interactive>:1:2: parse error on input ‘~’ Prelude> :k (~) (~) :: k -> k -> Constraint }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10059> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15297: Add support for insert, extract and broadcast SIMD instructions for native X86 codegen
by GHC 21 Jun '18

21 Jun '18

#15297: Add support for insert, extract and broadcast SIMD instructions for native X86 codegen -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15297> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 21 Jun '18

21 Jun '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS: the bad-ness of 'make clean' is also a worry. It wasted a lot of your time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:45> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 21 Jun '18

21 Jun '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 #15225 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well this is surprising news, but I think good news too. Maybe we can kill off the state hack altogether! But before we do that, let's really understand our data. (A minor point: in the nfib-analyse output, the column headings are cut off in the summary table; can you use shorter file names?) * I'm astounded by the reduction in compile time (and compiler allocation), in both variants. Is that caused by (a) a faster GHC stage 2, or (b) smaller Core sizes? Could you pick a module with a particularly big reduction, and dig into why? I confess that I am a bit suspicious. Compile times don't usually halve! * Binary sizes go up 5% when "GHC is compiled with -fno-state-hack". I think that the important thing is that the '''libraries''' (which are linked into the nofib binary) are compiled with -fno-state-hack. I doubt it's caused by the fact that ghc-stage2 is compiled with -fno-state-hack. Can you confirm? * And if binary sizes go up by 5% because the libraries are getting bigger, is that a generic 5% increase in .o file size? Or do a few key modules get a lot bigger? It's puzzling because the per-moudule "Module Sizes" stats in the nofib log suggest that there is an essentially-zero effect on nofib module sizes. * As I wrote above, the motivation for the state hack is functions lie {{{ f :: [Int] -> IO () f xs = print ys >> print xs where ys = reverse xs test 0 = return () test n = f [1,n] >> test (n-1) }}} which I expected to be much less efficient without the state hack. Would it be worth trying to demonstrate a program that does get worse in this way? I'm still amazed at how good the results are! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:44> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0