[GHC] #9718: Avoid TidyPgm predicting what CorePrep will do

[GHC]

#9718: Avoid TidyPgm predicting what CorePrep will do
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  (none)
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  7.8.3
      Resolution:                    |             Keywords:  CodeGen, CAFs
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 > I think the DLL stuff is not relevant to the task (we don't do any
 cross-module stuff)and the function (rhsIsStatic) is not used elsewhere,
 so it's fine to remove it.

 Probably.  But be careful here!  There is some platform-specific stuff in
 that function, so it might be fine on your platform but not on others.  I
 see stuff like
 {{{
 Top-level constructor applications can usually be allocated
 statically, but they can't if the constructor, or any of the
 arguments, come from another DLL (because we can't refer to static
 labels in other DLLs).

 If this happens we simply make the RHS into an updatable thunk,
 and 'execute' it rather than allocating it statically.
 }}}
 and
 {{{
     go (Var f) n_val_args
         | (platformOS platform /= OSMinGW32) ||
           not (is_dynamic_name (idName f))
 }}}
 I don't fully understand this, but it's all tied up with `isDllConApp`,
 which in turn is used in `CoreToStg`.  I believe that this code in
 `CoreToStg` nails it:
 {{{
   | StgConApp con args _ <- unticked_rhs
   , -- Dynamic StgConApps are updatable
     not (isDllConApp dflags this_mod con args)
   = -- CorePrep does this right, but just to make sure
     ASSERT2( not (isUnboxedTupleCon con || isUnboxedSumCon con)
            , ppr bndr $$ ppr con $$ ppr args)
     ( StgRhsCon dontCareCCS con args, ccs )
 }}}
 so we don't need to worry in our new (late) CAF analysis.
 But none of this DLL special casing is properly documented so I don't
 really understand what is happening.

 Returning to `rhsIsStatic` we have this:
 {{{
   is_static _      (Lit (LitLabel {}))    = False
   is_static _      (Lit _)                = True
         -- A LitLabel (foreign import "&foo") in an argument
         -- prevents a constructor application from being static.  The
         -- reason is that it might give rise to unresolvable symbols
         -- in the object file: under Linux, references to "weak"
         -- symbols from the data segment give rise to "unresolvable
         -- relocation" errors at link time This might be due to a bug
         -- in the linker, but we'll work around it here anyway.
         -- SDM 24/2/2004
 }}}
 No idea what this is about, but I wouldn't just delete it without thought.

 Finally, I see
 {{{
                 -- A naked un-applied variable is *not* deemed a static
 RHS
                 -- E.g.         f = g
                 -- Reason: better to update so that the indirection gets
 shorted
                 --         out, and the true value will be seen
                 -- NB: if you change this, you'll break the invariant that
 THUNK_STATICs
                 --     are always updatable.  If you do so, make sure that
 non-updatable
                 --     ones have enough space for their static link field!
 }}}
 I think this is probably again dealt with in `CoreToStg`.  If we have a
 bare variable as the RHS I think we get an updatable thunk.  I don't
 understand the bit about THUNK_STATIC though.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9718#comment:29>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler