[GHC] #2273: inlining defeats seq
GHC
trac at galois.com
Fri Oct 16 05:30:55 EDT 2009
#2273: inlining defeats seq
---------------------------------+------------------------------------------
Reporter: igloo | Owner:
Type: merge | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.9
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Comment (by simonpj):
Note to self. I think the Right Solution is simply not to inline things
that are "cheap", but only things that are "values". This is easy to
achieve:
{{{
hunk ./compiler/coreSyn/CoreUnfold.lhs 637
- yes_or_no = active_inline && is_cheap && consider_safe
+ yes_or_no = active_inline && is_value && consider_safe
}}}
But it's not quite so easy: this change makes allocation go up in a couple
of programs, and runtime goes up quite a bit. (We'd need to double-check
that the runtime figures are right.)
{{{
--------------------------------------------------------------------------------
Program Size Allocs Runtime Elapsed
--------------------------------------------------------------------------------
fulsom -2.8% +17.2% +39.1% +39.8%
puzzle +1.0% +8.1% +15.2% +18.6%
atom +0.7% +7.3% +55.7% +64.7%
circsim +0.5% -0.0% +35.2% +37.1%
compress2 +0.7% -0.0% +25.8% +29.9%
lcss +0.7% -0.0% +42.8% +48.1%
--------------------------------------------------------------------------------
Min -2.8% -4.3% -4.8% -10.0%
Max +1.0% +17.2% +55.7% +64.7%
Geometric Mean +0.5% +0.5% +18.2% +21.4%
}}}
So, annoyingly, more investigation required. I can't do it today, so I'm
recording the breadcrumbs here for when I get back to it.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2273#comment:10>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list