Warnings(?) about overlapping rules when building a debugged GHC

For a bit of time now I noticed that when I build a debugged + optimized GHC that I get a lot of warnings of the sort:

Rules.findBest: rule overlap (Rule 1 wins)
  Rule 1: "fromIntegral/a->Word32"
  Rule 2: "fromIntegral/CInt->a"
Rules.findBest: rule overlap (Rule 1 wins)
  Rule 1: "fromIntegral/a->Word32"
  Rule 2: "fromIntegral/CInt->a"
Rules.findBest: rule overlap (Rule 1 wins)
  Rule 1: "fromIntegral/Word32->a"
  Rule 2: "fromIntegral/a->CInt"
Rules.findBest: rule overlap (Rule 1 wins)
  Rule 1: "fromIntegral/a->Word32"
  Rule 2: "fromIntegral/CInt->a"
Rules.findBest: rule overlap (Rule 1 wins)
  Rule 1: "fromIntegral/Word32->a"
  Rule 2: "fromIntegral/a->CInt"

At worst that's an indication for an issue with our rules.
At best it's a lot of noise that might obscure more important debugging traces.

Either way the current state doesn't seem to be desireable. Maybe something could be done about that.

I think it started with d8dc0f96

Which added rules like:

"fromIntegral/a->Word32"       fromIntegral = \x -> case fromIntegral x of W# x# -> W32# (wordToWord32# x#)

which overlaps with the much older rules like this one:

"fromIntegral/CInt->a"    fromIntegral = \(CInt    x) -> fromIntegral x

The overlap seems to be harmless in this case. So perhaps we just have to live with that. But it does come at the cost of making the debug output less useful.

@hsyl20 Given that you added them maybe you have an idea how to avoid the status quo?