On skype we agreed that
- the the TcIface path doesn't need to even try to look for tuple names because they are encoded specially in interface files. We only need
#12357: Increasing maximum constraint tuple size significantly blows up compiler allocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Phab:D2400 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D2400 Comment: Phab:D2400 is also relevant here as it reworks the commit mentioned in comment:18. However, there is further change afoot: On Skype Simon and I discussed the current situation and agreed that it's still not quite right. He has summarized the conclusion on Phab:D2400, parse tuple names specially in the template haskell route.
- We'll put cons and nil and other special cases into the
OriginalNameCache so we don't need to parse them specially here; fewer special cases.
The point is that we needn't worry about the cost of including things like `(:)` and `[]` in the name cache, so we should just remove their cases from `isBuiltInOcc_maybe` and handle them in the usual way. The only cases which we should handle in `isBuiltInOcc_maybe` are those of tuples (of boxed, unboxed, and constraint varieties) and eventually unboxed sums. Additionally Simon proposed that we break up `lookupOrigNameCache` into two variants (names up for debate), * `lookupOrigNameCache'`, which will merely lookup an `OccName` in the name cache, without attempting to resolve built-in syntax (with an assert verifying that we aren't looking up something in `GHC.Tuple`, as definitions defined there aren't in the name cache) * `lookupOrigNameCache`, which will lookup an `OccName` as above, but also attempt to parse out names corresponding to built-in syntax. Then we can use `lookupOrigNameCache'` in the `ReadIface` codepaths, where we know that we should never see built-in syntax (since these names are encoded specially in the interface file symbol table, see `Note [Symbol table representation of names]` in `BinIface`). In the Template Haskell codepaths, it will still be necessary to use `lookupOrigNameCache`, to ensure that things like `mkName "(,)"` work. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12357#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler