[GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial

GHC ghc-devs at haskell.org
Wed Nov 2 13:56:36 UTC 2016


#11158: Combine exprIsTrivial and cpe_ExprIsTrivial
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:
            Type:  task              |               Status:  infoneeded
        Priority:  highest           |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  7.10.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D1656
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 Yesterday I start from a clean slate and started by again turning
 `cpe_ExprIsTrivial` calls into calls to `exprIsTrivial`. Recall that this
 essentially marks STG string and integer literals as non-trivial, ensuring
 that they are not duplicated in applications like ....

 After doing this I found that a `DEBUG` compiler build failed while
 building `GHC.Types` with an assertion failure in `CoreToStg`. Namely, the
 `consistentCafInfo` check failed as the `IdInfo` claimed `NoCafRefs` yet
 the binding itself was caffy. The binding in question is of the form,
 {{{#!hs
   $tcMode1 :: TrName
   [GblId, Caf=NoCafRefs, Str=m1] =
       \u []
           case "Mode"# of sat_swgf { __DEFAULT -> TrNameS [sat_swgf]; };
 }}}
 The reason `topStgBindHasCafRefs` considers this to be caffy is because
 the RHS is an updatable `StgRhsClosure`.

 It seems to me that the problem here is that we floated the string literal
 as an case analysis, meaning that we have turned what should be a
 `StgRhsCon` into a `StgRhsClosure`. I believe this is ultimately the same
 problem presented by #11312.

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


More information about the ghc-tickets mailing list