Fix Trac #3259: expose 'lazy' only after generating interface files
authorsimonpj@microsoft.com <unknown>
Fri, 29 May 2009 07:20:20 +0000 (07:20 +0000)
committersimonpj@microsoft.com <unknown>
Fri, 29 May 2009 07:20:20 +0000 (07:20 +0000)
commit0abcc75505992b925ca1b6fed6c97cb105b6fe96
treebbca10972edeb2dbaf7c216ddd26f9b483d37662
parent46f02d59813499ba2aa44e7831e0b69ec6d8f25d
Fix Trac #3259: expose 'lazy' only after generating interface files

This patch fixes an insidious and long-standing bug in the way that
parallelism is handled in GHC.  See Note [lazyId magic] in MkId.

Here's the diagnosis, copied from the Trac ticket.  par is defined
in GHC.Conc thus:

    {-# INLINE par  #-}
    par :: a -> b -> b
    par  x y = case (par# x) of { _ -> lazy y }

    -- The reason for the strange "lazy" call is that it fools the
    -- compiler into thinking that pseq and par are non-strict in
    -- their second argument (even if it inlines pseq/par at the call
    -- site).  If it thinks par is strict in "y", then it often
    -- evaluates "y" before "x", which is totally wrong.

The function lazy is the identity function, but it is inlined only
after strictness analysis, and (via some magic) pretends to be
lazy. Hence par pretends to be lazy too.

The trouble is that both par and lazy are inlined into your definition
of parallelise, so that the unfolding for parallelise (exposed in
Parallelise.hi) does not use lazy at all. Then when compiling Main,
parallelise is in turn inlined (before strictness analysis), and so
the strictness analyser sees too much.

This was all sloppy thinking on my part. Inlining lazy after
strictness analysis works fine for the current module, but not for
importing modules.

The fix implemented by this patch is to inline 'lazy' in CorePrep,
not in WorkWrap. That way interface files never see the inlined version.

The downside is that a little less optimisation may happen on programs
that use 'lazy'.  And you'll only see this in the results -ddump-prep
not in -ddump-simpl.  So KEEP AN EYE OUT (Simon and Satnam especially).
Still, it should work properly now.  Certainly fixes #3259.
compiler/basicTypes/MkId.lhs
compiler/coreSyn/CorePrep.lhs
compiler/stranal/WorkWrap.lhs