Integer constant folding in the presence of new primops

[Jan Stolarek]

> If you remove everything but the quotInteger test from
> integerConstantFolding and compile with -ddump-rule-rewrites then you'll
> see that the eqInteger rule fires before quotInteger. This is presumably
> comparing against 0, as the definition of quot for Integer (in GHC.Real)
> is
>     _ `quot` 0 = divZeroError
>     n `quot` d = n `quotInteger` d
Yes, I noticed these two rules firing together - perhaps that's the explanation why. I created a 
small program for testing:

main = print quotInt
quotInt :: Integer
quotInt = 100063 `quot` 156

I noticed that when I define eqInteger wrapper to be NOINLINE, the call to quot is translated to 
Core as:

Main.quotInt =
  GHC.Real.$fIntegralInteger_$cquot
    (__integer 100063) (__integer 156)

but when I change the wrapper to INLINE I get:

Main.quotInt =
  GHC.Real.$fNumRatio_$cquot             <-------- NumRatio instead of IntegralInteger
    (__integer 100063) (__integer 156)

All rule firing happens later (I used -ddump-simpl-iterations -ddump-rule-firings), except that 
for $fNumRatio_$cquot the quot rules don't fire.

> Do you also still have eqInteger wired in? It sounds like you might have
> given them both the same unique?
No, they didn't have the same unique. I modified the existing rules to work on the new primops and 
ignore their wrappers. At the moment I reverted these changes so that I can make progress and 
leave this problem for later.

Janek