OK, I attached an example for a specialization of Show for a special case of a custom type, like Ratio in
GHC.Real. My invokation with a custom GHC (8.0-based) was like this:
$ <ghc> Module.hs -ddump-simpl -O -fforce-recomp
At the begin of the log, I listed all exported top-level identifiers, the only interesting of which is `$fShowRatio :: Show a => Show (Ratio a)`, the default implementation. Note that at the bottom, there are RULEs stating the specialization for `Show Integer`, but that the specialized dictionary `$fShowRatio_$s$fShowRatio :: Show (Ratio Integer)` isn't otherwise reachable from any exported top-level identifier. Same goes for any of the specialized dictionary methods.
Now consider what happens if we request a `Show (Ratio Integer)` dictionary in another module: GHC finds the exported default dictionary `$fShowRatio :: Show a => Show (Ratio a)`, but then applies a specialization RULE that will effectively use the presumably absent `$fShowRatio_$s$fShowRatio :: Show (Ratio Integer)`.
In my case, my custom GHC would substitute away the `showString " % "` for an `absentError "lvl [Char]"` and crash in subtle ways. The only reason this isn't happening for GHC master is that DmdAnal does consider all top-level arguments to be used, instead of only the exported ones (which is what CallArity does).