[GHC] #10528: compile time performance regression with OverloadedStrings and Text
GHC
ghc-devs at haskell.org
Tue Aug 4 08:59:52 UTC 2015
#10528: compile time performance regression with OverloadedStrings and Text
-------------------------------------+-------------------------------------
Reporter: jakewheat | Owner:
Type: bug | Status: merge
Priority: high | Milestone: 7.10.3
Component: Compiler | Version: 7.10.2-rc2
Resolution: | Keywords:
Operating System: Linux | Architecture:
Type of failure: Compile-time | Unknown/Multiple
performance bug | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions:
-------------------------------------+-------------------------------------
Comment (by afarmer):
Ah, so much for my attempt to make my request seem like a non-HERMIT
issue. :-P
We would still like to have access to the original version of the rule
(without inlining/rule application being performed on either side) for
HERMIT's purposes. Is that possible? The rewriting of the RHS seems to
happen even if HERMIT is the very first phase of the core2core pipeline,
so I take it that it happens during desugaring? Might it be possible to
delay until the first simplifier pass runs?
To be concrete, I was proposing the following patch:
{{{
diff --git a/compiler/simplCore/Simplify.hs
b/compiler/simplCore/Simplify.hs
index d816d3f..f9e3f92 100644
--- a/compiler/simplCore/Simplify.hs
+++ b/compiler/simplCore/Simplify.hs
@@ -2969,10 +2969,9 @@ simplRules env mb_new_nm rules
, ru_fn = fn_name, ru_rhs = rhs
, ru_act = act })
= do { (env, bndrs') <- simplBinders env bndrs
- ; let lhs_env = updMode updModeForRuleLHS env
- rhs_env = updMode (updModeForStableUnfoldings act) env
- ; args' <- mapM (simplExpr lhs_env) args
- ; rhs' <- simplExpr rhs_env rhs
+ ; let env' = updMode updModeForRuleLHS env
+ ; args' <- mapM (simplExpr env') args
+ ; rhs' <- simplExpr env' rhs
; return (rule { ru_bndrs = bndrs'
, ru_fn = mb_new_nm `orElse` fn_name
, ru_args = args'
}}}
which gets our testsuite passing again.
I realize HERMIT support is probably not on GHC's critical path ;-) ...
I'm just trying to find a work around so we can support GHC 7.10. Thanks
for your help!
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10528#comment:37>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list