Too many warnings about consistentCafInfo

Building GHC with debug on yields in many (97!) warnings of the form

WARNING: file compiler/stgSyn/CoreToStg.hs, line 252
  $fFunctorIOEnv True False

The code in question is

-- Assertion helper: this checks that the CafInfo on the Id matches
-- what CoreToStg has figured out about the binding's SRT.  The
-- CafInfo will be exact in all cases except when CorePrep has
-- floated out a binding, in which case it will be approximate.
consistentCafInfo :: Id -> GenStgBinding Var Id -> Bool
consistentCafInfo id bind
  = WARN( not (exact || is_sat_thing) , ppr id <+> ppr id_marked_caffy <+> ppr binding_is_caffy )
    safe
  where
    safe  = id_marked_caffy || not binding_is_caffy
    exact = id_marked_caffy == binding_is_caffy
    id_marked_caffy  = mayHaveCafRefs (idCafInfo id)
    binding_is_caffy = topStgBindHasCafRefs bind
    is_sat_thing = occNameFS (nameOccName (idName id)) == fsLit "sat"

It would be nice to have less warnings, to make them more useful. I don’t know if the warning is not right, or if there is something that can be fixed about the thing it is warning about.

changed weight to 5

added Ttask Trac import labels

I agree. Potentially this a serious warning. Someone should look into it! It happens if

• The info about CAF-hood predicted by CorePrep differ from...
• the info about CAF-hood discovered by CoreToStg

I can advise.

As a systematic fix, I really want to get info about arity and CAF-hood from the CoreToStg pass, and NOT predict it in CorePrep.

I looked at this a little bit this morning but I don't understand this part of the compiler well enough.

Looking at the assertion code, it seems that binding_is_caffy is the truth about the binding and we are checking that it agrees with what we predicted earlier.

1. Why is this property checked at all?
2. Why it is predicted in CorePrep rather than discovered in CoreToStg?
3. How involved would it be to implement the suggestion in ticket:12650#comment:125486?

I also observed this with a dictionary like Joachim did in the original example so perhaps there is something slightly wrong with the analysis of dictionaries.

changed title from Too many warnigns about consistentCafInfo to Too many warnings about consistentCafInfo

changed the description

See #9718 (closed), which answers (2).

For (1) we check because if the predication is incorrect (e.g. says that it has no CAF refs when actually it does) we could fail to keep stuff alive during GC that was alive, with resulting seg-faults.

Re (3), not too hard! And very valuable. See #9718 (closed). I'm keen to get this done.

added Pnormal label

With 5ff0a171 consistentCafInfo no longer generates warnings; it's a compile-time panic with -dstg-lint or in debug builds, and previous warnings should be fixed as we have a CI job that tests with debug stage 1 and stage 2 compilers (validate-x86_64-linux-deb9-debug).

#9718 (closed) will be fixed with !1304 (merged).

closed