Unused arguments in join points

Sometimes GHC produces join points with unused parameters. In the example attached, we get join points like the following (when compiled with -O2):

...
    $j1_XHI
      :: GHC.Prim.Int#
         -> GHC.Types.Int
         -> (# Unboxed.FingerTree
                 Unboxed.Size (Unboxed.Node Unboxed.Size b_ahY),
               Unboxed.Node Unboxed.Size b_ahY,
               Unboxed.FingerTree
                 Unboxed.Size (Unboxed.Node Unboxed.Size b_ahY) #)
    [LclId, Arity=2, Str=DmdType LL]
    $j1_XHI =
      \ (x2_XE8 :: GHC.Prim.Int#) _ ->
...

which is always called as follows:

...
    $j1_XHI x2_XE2 (GHC.Types.I# x2_XE2)
...

i.e. where the second argument is a boxed version of the first. GHC should remove the dead parameter from the join point, to avoid unnecessary boxing.

I get this Core with 7.0.3 and with 7.1.20110629.

I've attached a self-contained example, as small as I can make it. (Making it smaller lets GHC do more unfolding and the problem disappears.) These join points occur inside the 'Deep' case of '$wsplitTree'.

Trac metadata

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

mentioned in issue #4941

mentioned in issue #5075 (closed)

changed weight to 5

added Tbug Trac import labels

Attached file Unboxed.hs ($603).

changed milestone to %7.4.1

assigned to @simonpj

Thanks for the report.

I've just tried this, and can't reproduce it. I used

ghc-7.0.3 -c -O2 -ddump-simpl T5302.hs

Can you try that and check what's happening?

But yes, I can just about see how this might happen. It would be dealt with by the fix we're investigating for #4941, namely running the strictness analyser a second time near the end.

Simon

Attached file T5302.hs ($610).

I can't reproduce either. I must have uploaded the wrong version of the file by mistake -- sorry.

The new file I just uploaded (T5302.hs) should work. With exactly the command you gave, look for the first join point inside the Deep case of wsplitTree. I get

                    $w$j_sIo
                      :: GHC.Prim.Int#
                         -> GHC.Prim.Int#
                         -> (# Unboxed.FingerTree
                                 Unboxed.Size (Unboxed.Node Unboxed.Size b_ak6),
                               Unboxed.Node Unboxed.Size b_ak6,
                               Unboxed.FingerTree
                                 Unboxed.Size (Unboxed.Node Unboxed.Size b_ak6) #)
                    [LclId, Arity=2, Str=DmdType LL]
                    $w$j_sIo =
                      \ (w2_sHj :: GHC.Prim.Int#) _ ->

So in this case the second argument is an Int# rather than an Int.

With

ghc-7.1.20110629 -c -O2 -ddump-simpl T5302.hs

I get

                $j_sJ4
                  :: GHC.Prim.Int#
                     -> GHC.Types.Int
                     -> (# Unboxed.FingerTree
                             Unboxed.Size (Unboxed.Node Unboxed.Size b_aiB),
                           Unboxed.Node Unboxed.Size b_aiB,
                           Unboxed.FingerTree
                             Unboxed.Size (Unboxed.Node Unboxed.Size b_aiB) #)
                [LclId, Arity=2, Str=DmdType LL]
                $j_sJ4 =
                  \ (x_aEm :: GHC.Prim.Int#) _ ->

in the same place. So in this case the second argument is an Int, as in my original report.

Attached file T5302_full.hs ($611).

As it can be somewhat subtle exactly when the unused argument arises (in particular, removing too much code causes the unused argument to disappear), I also attached a "less minimal" example. So the file T5302_full.hs is a less cut-down version of the T5302.hs, in case that is helpful. Run

ghc-7.0.3 -c -ddump-simpl -O2 T5302_full.hs

and as before, look for the first join point inside the Deep case of $wsplitTree.

changed milestone to %7.6.1

changed weight to 3

Trac metadata

Trac field	Value
Priority	normal → low

mentioned in issue #6087

changed milestone to %7.6.2

As of 321941a8, this test case (at less the _full.hs one) still generates the unused arguments. In fact, the join point under discussion also contains a join point with the same flaw. This happens with and without a SpecConstr.

In both cases, a late demand analysis removes both unnecessary arguments.

mentioned in issue #7782 (closed)

changed milestone to %7.10.1

Moving to 7.10.1.

removed milestone

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

changed milestone to %8.0.1

Milestone renamed

added join points label

changed milestone to %8.4.1

This does not appear to be fixed by the join point update. The second argument is still boxed.

The second argument is still boxed

Even with -O2 (which does a second demand/absence analysis pass? I think, though I have not dug into it, that the absence may only show up late.

Even if that's true, we should just check to ensure that there's no way it could have been caught in the first pass.

Still reproducible in HEAD.

• The reason the late demand-analysis doesn't catch it is because we don't do w/w. (Reason: see Note [Final Demand Analyser run] in DmdAnal.)
• The absent argument is actually a case binder, passed as a result of Note [Case binders and join points] in Simplify. But in this case it turns out that not only is the case-binder argument eventually unused, but (even worse) every juump to that join point looks like jump j x (I# x). So we box it, and then immediately discard it. Urk.

Just recording breadcrumbs for now. My thought: never pass the case binder to a join point; instead re-box it. It's much the same trade-off as in other places where we worry about re-boxing. And it would be a lot simpler; in particular, we can stop having unfoldings in lambda-binders, which is pretty dodgy anyway.

These tasks won't happen for 8.4 and have been sitting at low priority for quite some time. Consequently I am un-milestoning them. Don't let this stop you, the interested reader, from picking one up, however.

Just tried with GHC HEAD. Late demand analysis removes unused join point argument.

let-no-escape {
  $j_s4wc [Occ=Once*!T[2], Dmd=<C(C(S)),1*C1(C1(U(U,U)))>]
    :: GHC.Prim.Int#
       -> GHC.Types.Int
       -> (# Unboxed.FingerTree
               Unboxed.Size (Unboxed.Node Unboxed.Size c_s44z),
             Unboxed.FingerTree
               Unboxed.Size (Unboxed.Node Unboxed.Size c_s44z) #)
  [LclId[JoinId(2)], Arity=2, Str=<S,U><L,A>, Unf=OtherCon []] = ...

After:

let-no-escape {
  $w$j_s4BK [InlPrag=NOUSERINLINE[0],
             Occ=Once*!T[1],
             Dmd=<C(S),1*C1(U(U,U))>]
    :: GHC.Prim.Int#
       -> (# Unboxed.FingerTree
               Unboxed.Size (Unboxed.Node Unboxed.Size c_s45o),
             Unboxed.FingerTree
               Unboxed.Size (Unboxed.Node Unboxed.Size c_s45o) #)
  [LclId[JoinId(1)], Arity=1, Str=<S,U>, Unf=OtherCon []] = ...

Attached file Unboxed_late_dmd.dump-stg (download).

Unboxed.hs, late demand analysis

Attached file Unboxed_stock.dump-stg (download).

Unboxed.hs, default

removed join points label

added runtime perf label

added Plow label

I can confirm @osa1 findings from #5302 (comment 149055). What's the way forward for this ticket? Wasn't there a discussion whether -flate-dmd-anal could be included in -O2?

---

EDIT: Here's a version of the reproducer updated for compatibility with the Semigroup-Monoid-Proposal (GHC >= 8.0): T5302.hs

I have opened https://github.com/haskell/containers/issues/773 to discuss enabling -flate-dmd-anal in containers.

Wasn't there a discussion whether -flate-dmd-anal could be included in -O2

I think that idea seems plausible, and almost certainly a modest win (which is what we expect from -O2). It needs someone to try it out run all our benchmarks with and without this change. Pretty simple to do.

added demand analysis label

Adding @sgraf812

It seems this is a duplicate of #4941. One fix discussed above is to pass -flate-dmd-anal, but that is blocked on #6087. Closing this issue in favor of #4941.

closed