August 2016 - ghc-tickets

[GHC] #10766: user manual: INLINE's interaction with optimization levels is not clear
by GHC 03 Aug '16

03 Aug '16

#10766: user manual: INLINE's interaction with optimization levels is not clear -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.11 Documentation | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- user manual: INLINE's interaction with optimization levels is not clear From the user manual it's not possible to say how should INLINE and actual inlining behavior should interact with optimization levels. What the user manuals says: - Without INLINE GHC tries to inline depending on size of definitions and current optimization level(user manual says -O is needed, but can we assume that for any inlining to be done we need at least -O? Because I have an example in which inlining is happening even with -O0). - With INLINE GHC tries hard to inline. But it doesn't say which optimization level is needed. I think we should add word or two about this. Does anyone know the answer here? My guess is: Even though INLINE makes sure GHC saves RHS of the definition in .hi files to be able to inline later, optimization levels still have an effect on deciding whether to inline or not. Because some INLINEd RHSs may be too big in which case it may decide not to inline with -O1 but inline with -O2 etc. Furthermore, without -O, GHC doesn't mark definitions as INLINE. But if we have INLINEd definitions and compiling a code with -O0, it may still inline those definitions, because there are two different mechanisms to decide whether to mark as INLINE and whether to inline the RHS, and while without -O GHC doesn't mark anything as INLINE, it can still inline previously marked definitions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10766> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12453: Remove setUnfoldingInfoLazily
by GHC 03 Aug '16

03 Aug '16

#12453: Remove setUnfoldingInfoLazily -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering 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: -------------------------------------+------------------------------------- The definition of `setUnfoldingInfoLazily` is exactly the same as `setUnfoldingInfo` and is only used in one place, `TcInterface`. They were made equivalent in 2010 in 2ff2497dc374175b8ed81446258baf208d1f3e6e with the commit message. {{{ commit 2ff2497dc374175b8ed81446258baf208d1f3e6e Author: Ian Lynagh <igloo(a)earth.li> Wed Oct 20 15:37:10 2010 Committer: Ian Lynagh <igloo(a)earth.li> Wed Oct 20 15:37:10 2010 Original File: compiler/basicTypes/IdInfo.lhs Don't seq unfoldings We generate intermediate unfoldings which are just thrown away, so evaluating them is a waste of time. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200
by GHC 03 Aug '16

03 Aug '16

#11263: "Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 10527 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is perhaps the same bug as #10527 but I'm not sure, as it goes away with a modest bump to `-fsimpl-tick-factor`. I'm developing a library and am seeing this when I go to compile a small hello-world executable. {{{ <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $fMonadIdentity_$c>>= To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 6642 }}} If I remove the `INLINE` from the exported functions it goes away, but also makes the code much slower (for some reason the way I use the function in my benchmark suite doesn't exhibit the error). It also compiles with `-fsimpl-tick-factor=200`. Previously on 7.10.1 I got the same error in a different part of my code (the test suite) which went away when I moved to 7.10.3. If it's helpful I can upload the state of the repo, but it's not a small test case. Even if this is a duplicate, I'd love some guidance on this: Is this actually a ghc bug, or is it my fault that I've got too much inlining in my code (I've never seen anything like this before, and pretty much mark everything INLINE)? Should I pass this off to my users and should it be their responsibility to bump `-fsimpl-tick-factor` to work around regressions in their GHC? If I want to try to work around this in my library, what strategies could I employ (besides disabling inlining of exported functions)? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #7114: Cannot recover (good) inlining behaviour from 7.0.2 in 7.4.1
by GHC 03 Aug '16

03 Aug '16

#7114: Cannot recover (good) inlining behaviour from 7.0.2 in 7.4.1 -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Inlining 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7114#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7109: Inlining depends on datatype size, even with INLINE pragmas
by GHC 03 Aug '16

03 Aug '16

#7109: Inlining depends on datatype size, even with INLINE pragmas -------------------------------------+------------------------------------- Reporter: dreixel | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Inlining 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7109#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling)
by GHC 03 Aug '16

03 Aug '16

#3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.11 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -19,1 +19,1 @@ - More details, examples, and an informal spec: wiki:Inlining + More details, examples, and an informal spec: wiki:OldInlining New description: Inlining refers to the unfolding of definitions, ie replacing uses of identifiers with the definitions bound to them. Doing this at compile time can expose potential for other optimizations. As described in the User Guide, this is currently limited to non-recursive definitions, to avoid non-terminating recursion in the inliner. Unfolding Recursions Since many definitions in non-trivial programs are either recursive themselves or are built from recursion combinators, leaving recursion out of inlining alltogether is a serious limitation, especially in view of the encoding of loops via tail recursion. In conventional languages, loop transformations such as loop unrolling are at the heart of optimizing high performance code (for a useful overview, see Compiler Transformations for High-Performance Computing, ACM Computing Surveys, 1994). As a consequence, many performance-critical Haskell programs contain hand- unrolled and hand-peeled recursions, which is error-prone and obscures declarative contents. More details, examples, and an informal spec: wiki:OldInlining -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3123#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12274: GHC panic: simplifier ticks exhausted
by GHC 03 Aug '16

03 Aug '16

#12274: GHC panic: simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While compiling a project, I ran into this: {{{ Preprocessing library stache-0.1.0... [1 of 6] Compiling Text.Mustache.Type ( Text/Mustache/Type.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Text/Mustache/Type.o ) [.stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/autogen/cabal_macros.h changed] [2 of 6] Compiling Text.Mustache.Parser ( Text/Mustache/Parser.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Text/Mustache/Parser.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying RuleFired Class op HEq_sc To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 189602 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The code is available here: https://github.com/stackbuilders/stache This only happens with GHC 8.0, with 7.10 it just takes forever (which should be a known issue, with 7.8 it's much faster), but nevertheless finishes. With `-fsimpl-tick-factor=150` the build suceeded. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4960: Better inlining test in CoreUnfold
by GHC 03 Aug '16

03 Aug '16

#4960: Better inlining test in CoreUnfold -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: newcomer, | Inlining 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: newcomer => newcomer, Inlining -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4960#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper
by GHC 03 Aug '16

03 Aug '16

#5928: INLINABLE fails to specialize in presence of simple wrapper -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Inlining 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5928#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling)
by GHC 03 Aug '16

03 Aug '16

#3123: make INLINE work for recursive definitions (generalized loop peeling/loop unrolling) -------------------------------------+------------------------------------- Reporter: claus | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.11 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => invalid Comment: I'm going to close this as it isn't exactly clear what the suggestion is. Currently recursive definitions can be inlined but loop breakers are not inlined. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3123#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0