Commit c55bcbde authored by simonpj@microsoft.com's avatar simonpj@microsoft.com
Browse files

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!
parent 27497880
......@@ -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
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment