Add `-flate-dmd-anal` to `-O2`?

@sgraf812's summary:

This issue is quite long and the OP (which is a non-issue today, I think, even in 8.2 as of #6087 (comment 148337)) does not reflect at all what is discussed here.

Rather this issue seems about finding out why -flate-dmd-anal regresses NoFib and hence is not included in -O2. Reboxing was identified as the cause of this regression in #6087 (comment 149331). Simon concluded

Bottom line so far: late demand analysis can be a win, but only rarely so; and it can be a loss. It's a pity -- I'd like to make it part of -O2. But we probably have higher priorities for now.

But we have Boxity Analysis now as part of DmdAnal; it would be interesting to see the new NoFib numbers for -flate-dmd-anal.

---

Original issue description by @simonpj:

I came across this code in the nofib/spectral progam knights, in the code for KnightHeuristic.possibleMoves:

let {
  $j_sU3
    :: GHC.Types.Int -> GHC.Types.Int -> [KnightHeuristic.Direction]
  [LclId, Arity=2]
  $j_sU3 =
    \ (ww2_sRl :: GHC.Types.Int) (ww3_sRm :: GHC.Types.Int) ->
      case ww2_sRl of ww4_XQY { GHC.Types.I# ww5_sQU ->
      case GHC.Prim.>=# ww5_sQU 1 of _ {
        GHC.Types.False -> go1_azF ys_azM;
        GHC.Types.True ->
          case ds1_azR of _ { GHC.Types.I# y1_azp ->
          case GHC.Prim.<=# ww5_sQU y1_azp of _ {
            GHC.Types.False -> go1_azF ys_azM;
            GHC.Types.True ->
              case ww3_sRm of wild6_XAB { GHC.Types.I# x_XAE ->
              case GHC.Prim.>=# x_XAE 1 of _ {
                GHC.Types.False -> go1_azF ys_azM;
                GHC.Types.True ->
                  case GHC.Prim.<=# x_XAE y1_azp of _ {
                    GHC.Types.False -> go1_azF ys_azM;
                    GHC.Types.True ->
                      case GHC.List.notElem
                             @ ChessSetList.Tile
                             ChessSetList.isSquareFree_$dEq
                             (ww4_XQY, wild6_XAB)
                             wild2_azW
                      of _ {
                        GHC.Types.False -> go1_azF ys_azM;
                        GHC.Types.True ->
                          GHC.Types.:
                            @ KnightHeuristic.Direction y_azL (go1_azF ys_azM)
                      }
                  }
              }
              }
          }
          }
      }
      } } in
case y_azL of _ {
  KnightHeuristic.UL ->
    $j_sU3
      (case ww_sQJ of _ { GHC.Types.I# x_aya ->
       GHC.Types.I# (GHC.Prim.-# x_aya 1)
       })
      (case ww1_sQK of _ { GHC.Types.I# x_aya ->
       GHC.Types.I# (GHC.Prim.-# x_aya 2)
       });
  KnightHeuristic.UR ->
    $j_sU3
      (case ww_sQJ of _ { GHC.Types.I# x_ayl ->
       GHC.Types.I# (GHC.Prim.+# x_ayl 1)
       })
      (case ww1_sQK of _ { GHC.Types.I# x_aya ->
       GHC.Types.I# (GHC.Prim.-# x_aya 2)
       });

...lots more similar case alternatives follow...

Just look at all those Ints getting boxed, and the immediately unboxed by the join point! The strictness analyser would spot this easily, but presumably the join point is constructed after strictness analysis.

There must be an opportunity here to run a later strictness analysis pass.

Trac metadata

Trac field	Value
Version	7.4.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture