Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2013-01-08 Thread GHC 
#5928: INLINABLE fails to specialize in presence of simple wrapper
---+
  Reporter:  tibbe |  Owner:  
  Type:  bug   | Status:  new 
  Priority:  normal|  Milestone:  7.6.2   
 Component:  Compiler  |Version:  7.4.1   
Resolution:|   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+
Changes (by tibbe):

  * owner:  tibbe =>


Comment:

 I did some work here a while ago. From what I remember, these were the
 results:

 I tried to move the specialise pass later, after the main simplifier
 phases. That had a negative effect on the benchmarks I ran and also
 resulted in fewer specialisations, as measured by some instrumentation I
 added. I also tried to add a new specialise pass, again after the main
 simplifier phases, while leaving the original one (which runs after
 simpl_gently) untouched. This fixed my some specific case I had, but from
 what I remember it didn't get some other cases. I remember thinking that
 that particular approach worked well enough.

 I think this needs more investigation, like trying to specialise as part
 of the simplifier, but I'm not working on it at the moment. I will
 unassign this ticket for now to reflect that. I will assign the ticket to
 me again if I ever pick this up again.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2013-01-08 Thread GHC 
#5928: INLINABLE fails to specialize in presence of simple wrapper
---+
  Reporter:  tibbe |  Owner:  tibbe   
  Type:  bug   | Status:  new 
  Priority:  normal|  Milestone:  7.6.2   
 Component:  Compiler  |Version:  7.4.1   
Resolution:|   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+
Changes (by simonpj):

  * owner:  => tibbe


Comment:

 Thanks for running with this, Johan.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-11-30 Thread GHC 
#5928: INLINABLE fails to specialize in presence of simple wrapper
---+
  Reporter:  tibbe |  Owner:  
  Type:  bug   | Status:  new 
  Priority:  normal|  Milestone:  7.6.2   
 Component:  Compiler  |Version:  7.4.1   
Resolution:|   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:|  Blockedby:  
  Blocking:|Related:  
---+
Changes (by igloo):

  * status:  patch => new


Comment:

 It sounds like more investigation is needed on this.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-09-15 Thread GHC 
#5928: INLINABLE fails to specialize in presence of simple wrapper
-+--
Reporter:  tibbe |   Owner:  
Type:  bug   |  Status:  patch   
Priority:  normal|   Milestone:  7.6.2   
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by tibbe):

 After discussing with simonpj, I tried to instead move the existing
 specialise pass to after the simplifier pass. This hurt performance a bit
 (runtime +2.6%) and resulted in way fewer specialisations (down to 136
 from 230 for the whole nofib suite). Adding a second specialise pass (for
 a total of two) just after the main simplifier core pass increased the
 number of specialisations to 242, but showed no improvement in performance
 on nofib.

 The next step is probably to check why so many fewer specialisations were
 created when when the single passed was moved later in the pipeline.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-09-12 Thread GHC 
#5928: INLINABLE fails to specialize in presence of simple wrapper
-+--
Reporter:  tibbe |   Owner:  
Type:  bug   |  Status:  patch   
Priority:  normal|   Milestone:  7.6.2   
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by tibbe):

  * status:  new => patch


Comment:

 I've added an optional specialize pass after simplifier phases and just
 before spec-constr. This solves the issue in this ticket. To test
 compilations times I compiled the unordered-containers package with the
 new flag off (the default) and on. I see no changes in compilation times:

 {{{
 tibbe@redwood:ghc (always-specialize)$ time cabal install -w
 /Users/tibbe/src/ghc/inplace/bin/ghc-stage2 unordered-containers
 --reinstall
 Resolving dependencies...
 In order, the following will be installed:
 unordered-containers-0.2.2.1 (reinstall)
 Warning: Note that reinstalls are always dangerous. Continuing anyway...
 Configuring unordered-containers-0.2.2.1...
 Building unordered-containers-0.2.2.1...
 Preprocessing library unordered-containers-0.2.2.1...
 [1 of 8] Compiling Data.HashMap.UnsafeShift ( Data/HashMap/UnsafeShift.hs,
 dist/build/Data/HashMap/UnsafeShift.o )
 [2 of 8] Compiling Data.HashMap.PopCount ( Data/HashMap/PopCount.hs,
 dist/build/Data/HashMap/PopCount.o )
 [3 of 8] Compiling Data.HashMap.Unsafe ( Data/HashMap/Unsafe.hs,
 dist/build/Data/HashMap/Unsafe.o )
 [4 of 8] Compiling Data.HashMap.Array ( Data/HashMap/Array.hs,
 dist/build/Data/HashMap/Array.o )
 [5 of 8] Compiling Data.HashMap.Base ( Data/HashMap/Base.hs,
 dist/build/Data/HashMap/Base.o )
 [6 of 8] Compiling Data.HashMap.Strict ( Data/HashMap/Strict.hs,
 dist/build/Data/HashMap/Strict.o )
 [7 of 8] Compiling Data.HashMap.Lazy ( Data/HashMap/Lazy.hs,
 dist/build/Data/HashMap/Lazy.o )
 [8 of 8] Compiling Data.HashSet ( Data/HashSet.hs,
 dist/build/Data/HashSet.o )
 In-place registering unordered-containers-0.2.2.1...
 Running Haddock for unordered-containers-0.2.2.1...
 cabal: Haddock's internal GHC version must match the configured GHC
 version.
 The GHC version is 7.7.20120912 but haddock is using GHC version 7.4.1
 Installing library in
 /Users/tibbe/.cabal/lib/unordered-containers-0.2.2.1/ghc-7.7.20120912
 Registering unordered-containers-0.2.2.1...
 Installed unordered-containers-0.2.2.1

 real0m15.150s
 user0m14.602s
 sys 0m0.497s
 tibbe@redwood:ghc (always-specialize)$ time cabal install -w
 /Users/tibbe/src/ghc/inplace/bin/ghc-stage2 unordered-containers --ghc-
 option=-fspecialise-after --reinstall
 Resolving dependencies...
 In order, the following will be installed:
 unordered-containers-0.2.2.1 (reinstall)
 Warning: Note that reinstalls are always dangerous. Continuing anyway...
 Configuring unordered-containers-0.2.2.1...
 Building unordered-containers-0.2.2.1...
 Preprocessing library unordered-containers-0.2.2.1...
 [1 of 8] Compiling Data.HashMap.UnsafeShift ( Data/HashMap/UnsafeShift.hs,
 dist/build/Data/HashMap/UnsafeShift.o )
 [2 of 8] Compiling Data.HashMap.PopCount ( Data/HashMap/PopCount.hs,
 dist/build/Data/HashMap/PopCount.o )
 [3 of 8] Compiling Data.HashMap.Unsafe ( Data/HashMap/Unsafe.hs,
 dist/build/Data/HashMap/Unsafe.o )
 [4 of 8] Compiling Data.HashMap.Array ( Data/HashMap/Array.hs,
 dist/build/Data/HashMap/Array.o )
 [5 of 8] Compiling Data.HashMap.Base ( Data/HashMap/Base.hs,
 dist/build/Data/HashMap/Base.o )
 [6 of 8] Compiling Data.HashMap.Strict ( Data/HashMap/Strict.hs,
 dist/build/Data/HashMap/Strict.o )
 [7 of 8] Compiling Data.HashMap.Lazy ( Data/HashMap/Lazy.hs,
 dist/build/Data/HashMap/Lazy.o )
 [8 of 8] Compiling Data.HashSet ( Data/HashSet.hs,
 dist/build/Data/HashSet.o )
 In-place registering unordered-containers-0.2.2.1...
 Running Haddock for unordered-containers-0.2.2.1...
 cabal: Haddock's internal GHC version must match the configured GHC
 version.
 The GHC version is 7.7.20120912 but haddock is using GHC version 7.4.1
 Installing library in
 /Users/tibbe/.cabal/lib/unordered-containers-0.2.2.1/ghc-7.7.20120912
 Registering unordered-containers-0.2.2.1...
 Installed unordered-containers-0.2.2.1

 real0m15.164s
 user0m14.635s
 sys 0m0.495s
 }}}

 No measurable change in this case.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@ha

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-06-15 Thread GHC 
#5928: INLINABLE fails to specialize in presence of simple wrapper
-+--
Reporter:  tibbe |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  7.6.1   
   Component:  Compiler  | Version:  7.4.1   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by pcapriotti):

  * milestone:  => 7.6.1


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-06-05 Thread GHC 
#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   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by tibbe):

 Could we at least have the option of running the specialization pass more
 often (e.g. as often as inlining)? I'd like to have repa use INLINABLE
 instead of INLINE when possible to decrease the amount of code bloat it
 generates and I'd be worried that because the specialization pass only
 runs once it might fail to trigger in important situations and the
 performance of the code will be unpredictable.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-03-17 Thread GHC 
#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   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by milan):

 * cc: fox@… (added)


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-03-16 Thread GHC 
#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   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by tibbe):

 Replying to [comment:8 simonpj]:
 > Maybe so, but it ''still'' depends on the fragile property that `(!)` is
 inlined.

 True, but I don't think that's such a big deal. The surprising thing here
 is that `lookup` doesn't get specialized even though `(!)` is inlined.

 I think it's reasonable to expect uses to understand that if a function is
 large it might not get inlined and thus some optimization might not be
 exposed. It might even be reasonable to expect some optimizations to not
 fire if you manually delay inlining to some later phase. What is a bit
 unreasonable is that optimizations don't happen when things are expected
 to (and do) inline as early as they possibly could.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-03-16 Thread GHC 
#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   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by simonpj):

 Maybe so, but it ''still'' depends on the fragile property that `(!)` is
 inlined.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-03-16 Thread GHC 
#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   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by tibbe):

 I agree with Greg, unless specialization is very expensive, we should do
 it more often.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-03-16 Thread GHC 
#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   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by gregorycollins):

 simonpj: would it make sense to run a specialization pass after every
 inline pass?

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-03-16 Thread GHC 
#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   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by simonpj):

 I think it's because `(!)` just happens, by coincidence, to be small
 enough to inline all by itself.  But this inlining just happens to only
 occur after the specialisation pass.

 And it would not happen at all if `(!)` had been a bigger function, which
 is the typical case.  So, if `(!)` is big (or even, as we have seen, if
 it's small) you have to mark it INLINABLE.  Or, perhaps, as I say, you
 want every overloaded function to be inlinable, at least if you compile
 with -O2 perhaps?

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-03-16 Thread GHC 
#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   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--

Comment(by tibbe):

 Replying to [comment:3 simonpj]:
 > > Manually marking `(!)` as `INLINABLE` works, but users shouldn't have
 to do that.
 >
 > Why do you say that "users should not have to do that"?  Why are you
 happy to annotate `lookup` but not `(!)`?

 I should first clarify what I meant by "user." It's fine for me, the
 author of a high performance library, to have to understand the finer
 details of GHC performance tuning, as long as that performance tuning can
 be hidden inside the library.

 Now, should a user ''of my library'' have to understand how I use
 INLINABLE ''inside'' my library, or risk large performance degradations?
 I'd hope not, because if users need to have the same level of
 understanding as we who write these core libraries, everyone needs to be
 an expert to use the language.

 I suspect my choice of name for the wrapper, `(!)`, was a poor one, as it
 made it seem that it was part of the library when it was intended to
 represent a function defined outside the library. Here's what really
 happend:

  * In the unordered-containers library I defined `lookup`, but not `(!)`.
  * Lennart, who was porting some code from the containers library to the
 unordered-containers library, defined ''his'' own `(!)` function, in terms
 of ''my'' `lookup` function.
  * Lennart didn't put a INLINABLE pragma on ''his'' function, not knowing
 that this was needed to not lose the effect of the INLINABLE pragma I put
 on ''my'' `lookup` function.
  * Things didn't specialize; performance was poor.

 > Maybe your position is:
 >  * every overloaded function should be `INLINABLE`.
 > If that was the rule then all overloading would be specialised, at the
 cost of some code duplication.  But it's not the rule at the moment.   I
 guess we could have a flag to give that behaviour -- but then you'd  have
 to remember to use it.

 I don't think the lack of such a rule is the problem here. Look at this
 core:

 {{{
 Test.test1 =
   Data.HashMap.Base.lookup
 @ GHC.Types.Int
 @ GHC.Types.Int
 GHC.Classes.$fEqInt
 Data.Hashable.$fHashableInt
 Test.test2
 }}}

 Why is `lookup` being passed two dictionaries when it's marked as
 INLINABLE? This ought to have triggered a specialization.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-03-16 Thread GHC 
#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   
Keywords:|  Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  | Failure:  None/Unknown
  Difficulty:  Unknown   |Testcase:  
   Blockedby:|Blocking:  
 Related:|  
-+--
Changes (by simonpj):

  * difficulty:  => Unknown


Comment:

 > Manually marking `(!)` as `INLINABLE` works, but users shouldn't have to
 do that.

 Why do you say that "users should not have to do that"?  Why are you happy
 to annotate `lookup` but not `(!)`?

 Maybe your position is:
  * every overloaded function should be `INLINABLE`.
 If that was the rule then all overloading would be specialised, at the
 cost of some code duplication.  But it's not the rule at the moment.   I
 guess we could have a flag to give that behaviour -- but then you'd  have
 to remember to use it.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-03-12 Thread GHC 
#5928: INLINABLE fails to specialize in presence of simple wrapper
--+-
 Reporter:  tibbe |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Compiler
  Version:  7.4.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-
Changes (by PHO):

 * cc: pho@… (added)


-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #5928: INLINABLE fails to specialize in presence of simple wrapper

2012-03-11 Thread GHC 
#5928: INLINABLE fails to specialize in presence of simple wrapper
--+-
 Reporter:  tibbe |  Owner:  
 Type:  bug   | Status:  new 
 Priority:  normal|  Component:  Compiler
  Version:  7.4.1 |   Keywords:  
   Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
  Failure:  None/Unknown  |   Testcase:  
Blockedby:|   Blocking:  
  Related:|  
--+-

Comment(by tibbe):

 This
 
[https://github.com/haskell/containers/commit/3f798e333509f02eb44d39a41068c76863064097
 commit to the containers library] by Milan Straka seems relevant.

 Relevant part of commit message:

 {{{
 * In GHC, INLINing the INLINABLE method as in
 update f = updateWithKey (\_ x -> f x)
 {-# INLINE update #-}
 updateWithKey = ...
 {-# INLINABLE updateWithKey #-}
   does not produce wanted result -- the updateWithKey does not get
   specialized in the call-site module.

   The solution is to mark both functions INLINABLE.
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs