From c55bcbdea7b8122956853c90f680a59808889b95 Mon Sep 17 00:00:00 2001 From: "simonpj@microsoft.com" Date: Wed, 17 May 2006 15:47:25 +0000 Subject: [PATCH] Retain InlinePragInfo on wrappers For some reason, when doing the worker/wrapper split, we transferred the InlinePragInfo from the original function, but expunging it from the wrapper. This meant, for example, that a NOINLINE function would have its wrapper inlined, which isn't sensible. For a change, fixing a bug involves only deleting code! --- compiler/stranal/WorkWrap.lhs | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/compiler/stranal/WorkWrap.lhs b/compiler/stranal/WorkWrap.lhs index d964026..1010699 100644 --- a/compiler/stranal/WorkWrap.lhs +++ b/compiler/stranal/WorkWrap.lhs @@ -256,14 +256,19 @@ splitFun fn_id fn_info wrap_dmds res_info inline_prag rhs work_rhs = work_fn rhs work_id = mkWorkerId work_uniq fn_id (exprType work_rhs) `setInlinePragma` inline_prag + -- Any inline pragma (which sets when inlining is active) + -- on the original function is duplicated on the worker and wrapper + -- It *matters* that the pragma stays on the wrapper + -- It seems sensible to have it on the worker too, although we + -- can't think of a compelling reason. (In ptic, INLINE things are + -- not w/wd) `setIdNewStrictness` StrictSig (mkTopDmdType work_demands work_res_info) -- Even though we may not be at top level, -- it's ok to give it an empty DmdEnv wrap_rhs = wrap_fn work_id wrap_id = fn_id `setIdWorkerInfo` HasWorker work_id arity - `setInlinePragma` AlwaysActive -- Zap any inline pragma; - -- Put it on the worker instead + in returnUs ([(work_id, work_rhs), (wrap_id, wrap_rhs)]) -- Worker first, because wrapper mentions it -- 1.7.10.4