Commit e07211f7 authored by Joachim Breitner's avatar Joachim Breitner
Browse files

Zap Call Arity info in the simplifier

As #13479 shows, there are corner cases where the simplifier decides to
not eta-expand a function as much as its call arity would suggest, but
instead transforms the code that the call arity annotation becomes a

As the call arity information is only meant to be used by the
immediatelly following simplifier run, it makes sense to simply zap the
information there.

Differential Revision:
parent c77551ab
......@@ -29,7 +29,7 @@ module IdInfo (
-- ** Zapping various forms of Info
zapLamInfo, zapFragileInfo,
zapDemandInfo, zapUsageInfo, zapUsageEnvInfo, zapUsedOnceInfo,
zapTailCallInfo, zapCallArityInfo,
-- ** The ArityInfo type
......@@ -553,6 +553,9 @@ zapTailCallInfo info
safe_occ = occ { occ_tail = NoTailCallInfo }
zapCallArityInfo :: IdInfo -> IdInfo
zapCallArityInfo info = setCallArityInfo info 0
* *
......@@ -803,7 +803,12 @@ completeBind env top_lvl is_rec mb_cont old_bndr new_bndr new_rhs
| otherwise
= info2
final_id = new_bndr `setIdInfo` info3
-- Zap call arity info. We have used it by now (via
-- `tryEtaExpandRhs`), and the simplifier can invalidate this
-- information, leading to broken code later (e.g. #13479)
info4 = zapCallArityInfo info3
final_id = new_bndr `setIdInfo` info4
; -- pprTrace "Binding" (ppr final_id <+> ppr new_unfolding) $
return (addNonRec env final_id final_rhs) } }
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment