Integer constant folding in the presence of new primops

[Ian Lynagh]

On Fri, May 17, 2013 at 11:49:26AM +0200, Jan Stolarek wrote:
> 
> Now here's the tricky part. I'm testing this with test lib/integer/integerConstantFolding in the 
> testsuite and the test fails because rules for quotRemInteger, divModInteger, quotInteger and 
> remInteger don't fire, leaving the constants unfolded. I noticed that if I mark eqInteger with 
> NOINLINE, then these rules fire, but then obviously comparisons like (100012 :: Integer) == 
> 100012 don't get folded and the test fails anyway. I'm analyzing how the function quotInteger and 
> others use eqInteger, but I don't see anything that would be obvious.

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

> eqIntegerPrimIdKey      = mkPreludeMiscIdUnique 70
> eqIntegerPrimName     = varQual gHC_INTEGER_TYPE (fsLit "eqIntegerPrim")     eqIntegerPrimIdKey

Do you also still have eqInteger wired in? It sounds like you might have
given them both the same unique?


Thanks
Ian
-- 
Ian Lynagh, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/