Skip to content

Draft: s/NOINLINE/NOINLINE[0]/g in GHC.Num.Integer (#18765)

Sebastian Graf requested to merge wip/T18765 into master

This defeats constant-folding in the final phases of the Simplifier, but enables us to get rid of allocations by inlining calls that can't be constant-folded.

NOINLINE[0] is a better choice than NOINLINE, because

  1. We still delay inlining long enough for the constant-folding RULEs to fire
  2. The compiler has the option to inlining them late, possibly cancelling away boxes in the process.

NOINLINE[0] is a better choice than INLINE[0], because

  1. We don't unconditionally inline huge definitions such as integerDiv, which would lead to code bloat at pretty much no gain.
  2. Since RULEs are unlikely to fire on the inlined RHS of e.g. integerDiv, there is no gain in inlining the unoptimised unfoldings.

Fixes #18765 (closed).

Edited by Andreas Klebinger

Merge request reports