summaryrefslogtreecommitdiff
path: root/compiler/GHC/Core/Opt/Simplify/Utils.hs
diff options
context:
space:
mode:
authorBen Gamari <ben@smart-cactus.org>2019-12-29 07:51:15 +0000
committerBen Gamari <ben@smart-cactus.org>2020-05-21 11:35:57 -0400
commit8cbfcac64e6650badcd99a3d189801e7d9faa3cb (patch)
tree87a2caa4defa5c61910d3b4d89e989bc74495f91 /compiler/GHC/Core/Opt/Simplify/Utils.hs
parent568d7279a80cf945271f0659f11a94eea3f1433d (diff)
downloadhaskell-8cbfcac64e6650badcd99a3d189801e7d9faa3cb.tar.gz
simplCore: Ignore ticks in rule templateswip/T17619
This fixes #17619, where a tick snuck in to the template of a rule, resulting in a panic during rule matching. The tick in question was introduced via post-inlining, as discussed in `Note [Simplifying rules]`. The solution we decided upon was to simply ignore ticks in the rule template, as discussed in `Note [Tick annotations in RULE matching]`. Fixes #18162. Fixes #17619.
Diffstat (limited to 'compiler/GHC/Core/Opt/Simplify/Utils.hs')
-rw-r--r--compiler/GHC/Core/Opt/Simplify/Utils.hs19
1 files changed, 19 insertions, 0 deletions
diff --git a/compiler/GHC/Core/Opt/Simplify/Utils.hs b/compiler/GHC/Core/Opt/Simplify/Utils.hs
index 87948ff6c1..aad3629b1c 100644
--- a/compiler/GHC/Core/Opt/Simplify/Utils.hs
+++ b/compiler/GHC/Core/Opt/Simplify/Utils.hs
@@ -830,6 +830,21 @@ Ticks into the LHS, which makes matching trickier. #10665, #10745.
Doing this to either side confounds tools like HERMIT, which seek to reason
about and apply the RULES as originally written. See #10829.
+There is, however, one case where we are pretty much /forced/ to transform the
+LHS of a rule: postInlineUnconditionally. For instance, in the case of
+
+ let f = g @Int in f
+
+We very much want to inline f into the body of the let. However, to do so (and
+be able to safely drop f's binding) we must inline into all occurrences of f,
+including those in the LHS of rules.
+
+This can cause somewhat surprising results; for instance, in #18162 we found
+that a rule template contained ticks in its arguments, because
+postInlineUnconditionally substituted in a trivial expression that contains
+ticks. See Note [Tick annotations in RULE matching] in GHC.Core.Rules for
+details.
+
Note [No eta expansion in stable unfoldings]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If we have a stable unfolding
@@ -1251,6 +1266,10 @@ it's best to inline it anyway. We often get a=E; b=a from desugaring,
with both a and b marked NOINLINE. But that seems incompatible with
our new view that inlining is like a RULE, so I'm sticking to the 'active'
story for now.
+
+NB: unconditional inlining of this sort can introduce ticks in places that
+may seem surprising; for instance, the LHS of rules. See Note [Simplfying
+rules] for details.
-}
postInlineUnconditionally