[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