Integer constant folding in the presence of new primops

[Jan Stolarek]

> If it's not sorted out, can you open a ticket, put in the relevant info (so
> we don't need to look at the email trail), and we can tackle it when you
> get here.
Currently there's a temporary workaround: I'm using new folding rules for all primitive types, 
except for Integer, in which case I left the old folding rules unchanged. This of course should 
be modified to make all rules uniform, but for now it at least passes validation. I didn't fill 
the ticket, because the bug does not exist yet :) It only manifests itself in my patches, which 
have not been applied yet. I'll add all the information from this discussion to my github fork of 
GHC and then move it to Trac once the bug makes it to HEAD.

What worries me more about my patches is the performance regression in kahan, because I see no 
obvious differences in the generated assembly.

Janek

>
> Simon
>
> -----Original Message-----
> From: ghc-devs-bounces at haskell.org [mailto:ghc-devs-bounces at haskell.org] On
> Behalf Of Jan Stolarek Sent: 20 May 2013 12:35
> To: Ian Lynagh
> Cc: ghc-devs at haskell.org
> Subject: Re: Integer constant folding in the presence of new primops
>
> > 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
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs