Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : supercompiler
http://hackage.haskell.org/trac/ghc/changeset/61f74db90cba9d4e5b9d9a9207f1cba6311dc0ff >--------------------------------------------------------------- commit 61f74db90cba9d4e5b9d9a9207f1cba6311dc0ff Author: Max Bolingbroke <batterseapo...@hotmail.com> Date: Fri Nov 16 14:11:22 2012 +0000 Ensure wrappers are SUPERINLINABLE >--------------------------------------------------------------- compiler/supercompile/Supercompile.hs | 1 + .../Supercompile/Evaluator/Evaluate.hs | 3 +++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/compiler/supercompile/Supercompile.hs b/compiler/supercompile/Supercompile.hs index 4dad93c..ae08183 100644 --- a/compiler/supercompile/Supercompile.hs +++ b/compiler/supercompile/Supercompile.hs @@ -191,6 +191,7 @@ termUnfoldings {-mod_finder-} e = go (S.termFreeVars e) emptyVarSet [] [] -- We still do check shouldExposeUnfolding here because we can avoid parsing+tagging those unfoldings -- which can literall never be used. varUnfolding x + -- NB: probably want to ensure these are all considered superinlinable by shouldExposeUnfolding for the evaluator | Just pop <- isPrimOpId_maybe x = Right $ primOpUnfolding pop | Just dc <- isDataConWorkId_maybe x = dataUnfolding dc | otherwise = case S.shouldExposeUnfolding x of diff --git a/compiler/supercompile/Supercompile/Evaluator/Evaluate.hs b/compiler/supercompile/Supercompile/Evaluator/Evaluate.hs index fe196cf..d3556bf 100644 --- a/compiler/supercompile/Supercompile/Evaluator/Evaluate.hs +++ b/compiler/supercompile/Supercompile/Evaluator/Evaluate.hs @@ -562,6 +562,9 @@ shouldExposeUnfolding x = case inl_inline inl_prag of _ | Just mod <- nameModule_maybe (idName x) , moduleName mod `elem` map mkModuleName ["Data.Complex", "GHC.List"] -> Right True + -- These get wrappers generated for them: be very eager to inline the wrappers + | isPrimOpId x || isDataConWorkId x + -> Right True -- NB: we don't check the activation on INLINE things because so many activations -- are used to ensure that e.g. RULE-based fusion works properly, and NOINLINE will -- generally impede supercompiler-directed fusion. _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
