[GHC] #14037: Fix fusion for GHC's utility functions

GHC ghc-devs at haskell.org
Thu Jul 27 11:49:37 UTC 2017


#14037: Fix fusion for GHC's utility functions
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Richard Eisenberg <rae@…>):

 In [changeset:"fb752133f45f01b27240d7cc6bce2063a015e51b/ghc" fb75213/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="fb752133f45f01b27240d7cc6bce2063a015e51b"
 Track visibility in TypeEqOrigin

 A type equality error can arise from a mismatch between
 *invisible* arguments just as easily as from visible arguments.
 But we should really prefer printing out errors from visible
 arguments over invisible ones. Suppose we have a mismatch between
 `Proxy Int` and `Proxy Maybe`. Would you rather get an error
 between `Int` and `Maybe`? Or between `*` and `* -> *`? I thought
 so, too.

 There is a fair amount of plumbing with this one, but I think
 it's worth it.

 This commit introduces a performance regression in test
 perf/compiler/T5631. The cause of the regression is not the
 new visibility stuff, directly: it's due to a change from
 zipWithM to zipWith3M in TcUnify. To my surprise, zipWithM
 is nicely optimized (it fuses away), but zipWith3M is not.
 There are other examples of functions that could be made faster,
 so I've posted a separate ticket, #14037, to track these
 improvements. For now, I've accepted the small (6.6%) regression.
 }}}

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14037#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list