Note [Side-effects and strictness]

Due to historic reasons and the continued effort not to cause performance
regressions downstream, Strictness Analysis is currently prone to discarding
observable side-effects (other than precise exceptions, see
Note [Precise exceptions and strictness analysis]) in some cases. For example,
  f :: MVar () -> Int -> IO Int
  f mv x = putMVar mv () >> (x `seq` return x)
The call to `putMVar` is an observable side-effect. Yet, Strictness Analysis
currently concludes that `f` is strict in `x` and uses call-by-value.
That means `f mv (error "boom")` will error out with the imprecise exception
rather performing the side-effect.

This is a conscious violation of the semantics described in the paper
"a semantics for imprecise exceptions"; so it would be great if we could
identify the offending primops and extend the idea in
Note [Which scrutinees may throw precise exceptions] to general side-effects.

Unfortunately, the existing has-side-effects classification for primops is
too conservative, listing `writeMutVar#` and even `readMutVar#` as
side-effecting. That is due to #3207. A possible way forward is described in
#17900, but no effort has been so far towards a resolution.