Problem
Generated output contains verbatim repeats of pure subexpressions. In Data.String.CodePoints.unsafeCodePointAt0 the charAt lambda is pasted twice (two applications with different arguments but an identical lambda body); dictionary projections and compare(dictOrd)-style chains repeat within one body. Each repeat is a repeated closure allocation and repeated calls at runtime.
Approach
Binding-level CSE in the IR: alpha-equivalent subexpressions within one body are hoisted into a shared Let binding. The strictness caveat bounds the scope: hoisting an expression that would only have evaluated in one branch into a dominating Let introduces divergence or exceptions where none existed. Hence the pass only touches forms that are effect-free by construction — lambda literals (closure allocation is pure; exactly the charAt case), literals, saturated Ctor applications, and projections out of refs — never arbitrary applications. GHC's CSE pass with its sharing restrictions is the precedent (see docs/OPTIMIZATIONS_SURVEY.md).
Prerequisites / Relations
No prerequisites; independent in the dependency graph. Relates only to #172, which would register the effect.
Verification / Measurement
The duplicated charAt lambda in Data.String.CodePoints.unsafeCodePointAt0 is emitted once (hoisted into a shared Let) instead of pasted twice. The win is small-to-medium and allocation-shaped, so it shows up indirectly in #172 (code size, allocation counters) rather than as a headline speed-up. Because the pass moves expressions, stress the randomized optimizer specs across seeds to confirm no branch-conditional evaluation is hoisted.
Problem
Generated output contains verbatim repeats of pure subexpressions. In
Data.String.CodePoints.unsafeCodePointAt0thecharAtlambda is pasted twice (two applications with different arguments but an identical lambda body); dictionary projections andcompare(dictOrd)-style chains repeat within one body. Each repeat is a repeated closure allocation and repeated calls at runtime.Approach
Binding-level CSE in the IR: alpha-equivalent subexpressions within one body are hoisted into a shared Let binding. The strictness caveat bounds the scope: hoisting an expression that would only have evaluated in one branch into a dominating Let introduces divergence or exceptions where none existed. Hence the pass only touches forms that are effect-free by construction — lambda literals (closure allocation is pure; exactly the
charAtcase), literals, saturatedCtorapplications, and projections out of refs — never arbitrary applications. GHC's CSE pass with its sharing restrictions is the precedent (see docs/OPTIMIZATIONS_SURVEY.md).Prerequisites / Relations
No prerequisites; independent in the dependency graph. Relates only to #172, which would register the effect.
Verification / Measurement
The duplicated
charAtlambda inData.String.CodePoints.unsafeCodePointAt0is emitted once (hoisted into a shared Let) instead of pasted twice. The win is small-to-medium and allocation-shaped, so it shows up indirectly in #172 (code size, allocation counters) rather than as a headline speed-up. Because the pass moves expressions, stress the randomized optimizer specs across seeds to confirm no branch-conditional evaluation is hoisted.