Demand: Let `Boxed` win in `lubBoxity`
This ticket tracks the motivation for !7609 (closed).
!5790 (closed) introduced a rather gross hack to work around various regressions introduced by conservative boxity analysis.
We let Unboxed
win in lubBoxity
, which is unsoundly optimistic. "Unsoundly" in the sense that we sometimes unbox parameters that we better shouldn't unbox. Here's a list where that bites us:
-
#18907 (closed) and
T19871.absent
unbox huge records when they shouldn't - In #20746 (closed), we saw that the simple definition of
deferAfterPreciseException = lubDmdType exnDmdTyp
unboxes hugeHandle
types inGHC.IO.Handle.Text
, although all actual use sites of theHandle
wereBoxed
. The reason we unboxed it was theUnboxed
flag coming from the absent free variable demand ofexnDmdType
, which will ultimately win against theBoxed
use sites. - The implementation of
lubDmd
became complex to reason about, working around the issue of too much (and unsound) unboxing by lettingBoxed
win whenlub
bing with the bottom demandB
, whereas whenlub
bing withA
, we letUnboxed
win. -
#20767 (closed) gives other, similar examples where we show that
B
andL
aren't actually bottom and top of the lattice at the moment. That's terrible! - In the implementation of !7599 (merged), which fixes #21081 (closed), I found that I had contradicting requirements of
lub
andplus
because of these last two points.