+Note [INLINE and NOINLINE]
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+We are careful to do no CSE inside functions that the user has marked as
+INLINE or NOINLINE. In terms of Core, that means
+
+ a) we do not do CSE inside (Note InlineMe e)
+
+ b) we do not do CSE on the RHS of a binding b=e
+ unless b's InlinePragma is AlwaysActive
+
+Here's why (examples from Roman Leshchinskiy). Consider
+
+ yes :: Int
+ {-# NOINLINE yes #-}
+ yes = undefined
+
+ no :: Int
+ {-# NOINLINE no #-}
+ no = undefined
+
+ foo :: Int -> Int -> Int
+ {-# NOINLINE foo #-}
+ foo m n = n
+
+ {-# RULES "foo/no" foo no = id #-}
+
+ bar :: Int -> Int
+ bar = foo yes
+
+We do not expect the rule to fire. But if we do CSE, then we get
+yes=no, and the rule does fire. Worse, whether we get yes=no or
+no=yes depends on the order of the definitions.
+
+In general, CSE should probably never touch things with INLINE pragmas
+as this could lead to surprising results. Consider
+
+ {-# INLINE foo #-}
+ foo = <rhs>
+
+ {-# NOINLINE bar #-}
+ bar = <rhs> -- Same rhs as foo
+
+If CSE produces
+ foo = bar
+then foo will never be inlined (when it should be); but if it produces
+ bar = foo
+bar will be inlined (when it should not be). Even if we remove INLINE foo,
+we'd still like foo to be inlined if rhs is small. This won't happen
+with foo = bar.
+
+Not CSE-ing inside INLINE also solves an annoying bug in CSE. Consider
+a worker/wrapper, in which the worker has turned into a single variable:
+ $wf = h
+ f = \x -> ...$wf...
+Now CSE may transoform to
+ f = \x -> ...h...
+But the WorkerInfo for f still says $wf, which is now dead! This won't
+happen now that we don't look inside INLINEs (which wrappers are).
+