The problem are not so much the additional instructions. Rather, it's the fact that compare for Float and Double can fail at all which inhibits some optimisations. For instance, GHC is free to eliminate the comparison in (x `compare` y) `seq` a but wouldn't be with your change. It doesn't actually do that at the moment, which looks like an optimiser deficiency to me. But in any case, the property "can fail" has a significant effect on optimisations sometimes.
Yeah, the IEEE FP people knew what they were doing from a performance perspective. This kind of problem (eg, being able to remove a dead x+y without proving all kinds of conditions on x and y) is exactly whey they mandated a NaN value upon arithmetic exception rather than making the computation fail with a synchronous exception. Or at least, a mode, almost always used by default, with this behaviour. What you're describing is a similar performance problem, which argues for a similar solution: data Ordering = LT, EQ, GT, OoO where OoO means Out of Order. But just because you could doesn't mean you'd have to do this: compare x y = case map (\o->x`o`y) [(<),(<=),(==),(>=),(>),(/=)] of [True,True,False,False,False,True] -> LT [False,True,True,True,False,False] -> EQ [False,False,False,True,True,True] -> GT otherwise -> OoO --Barak.