OK. I thought it only applies to RULES pragma. Janek
Dnia środa, 24 kwietnia 2013, Simon Peyton-Jones napisał: > Use -ddump-rule-firings to display rule firings > > Simon > > | -----Original Message----- > | From: Jan Stolarek [mailto:[email protected]] > | Sent: 24 April 2013 07:53 > | To: Simon Peyton-Jones > | Cc: [email protected] > | Subject: Re: Handling of NaN > | > | Is there a way of measuring how often such a rule is triggered? I think > | no programmer will write a program which explicitly compares two > | floating point literals, but I'd like to know how often such cases > | result from program transformation. > | > | Janek > | > | Dnia wtorek, 23 kwietnia 2013, Simon Peyton-Jones napisał: > | > Just so. You could make a float rule that constant-folded > | > lit1 == lit2 > | > to True if lit1 and lit2 were the same, and were not NaNs. > | > > | > As you point out, being syntactically equal expressions isn't enough. > | > > | > Simon > | > > | > | -----Original Message----- > | > | From: Jan Stolarek [mailto:[email protected]] > | > | Sent: 23 April 2013 09:46 > | > | To: Simon Peyton-Jones > | > | Cc: [email protected] > | > | Subject: Re: Handling of NaN > | > | > | > | > The rule can test for NaNs, but behave as before for non-NaNs. > | > | > That > | > | > | > | might be best, no? > | > | I was thinking about that, but then I thought about such code: > | > | > | > | f :: Bool > | > | f = go 1 == go 2 > | > | where nan = 0.0 / 0.0 :: Double > | > | go n = if not (isPrime (n * n - n + 41)) > | > | then nan > | > | else go (n + 1) > | > | > | > | The compiler would not be able to tell whether 'go' reduces to NaN > | > | or not (perhaps not the best possible example because the > | > | alternative value is _|_). It would be possible to test for NaNs in > | > | some trivial cases where one of the operands really is a NaN, but in > | > | general I believe it is impossible to test whether the expression > | > | reduces to NaN or not. And the rules need to be correct > | > | *always* not *sometimes*. Am I missing something? The only thing > | > | that comes to my mind is writing a rule that works only on literals, > | > | because for literals we can be sure they are not NaNs (on the other > | > | hand I doubt this rule would trigger often). > | > | > | > | Janek > | > | > | > | > Simon > | > | > > | > | > | -----Original Message----- > | > | > | From: Jan Stolarek [mailto:[email protected]] > | > | > | Sent: 22 April 2013 15:51 > | > | > | To: Simon Peyton-Jones > | > | > | Cc: [email protected] > | > | > | Subject: Re: Handling of NaN > | > | > | > | > | > | > Same happens in HEAD, so nothing to do with your changes. > | > | > | > | > | > | I didn't notice that, I was comparing against 7.6.2 :/ > | > | > | > | > | > | > Better define mkFloatingRelOpRule instead, which doesn't have > | > | > | > the > | > | > | > | > | > | equal-args thing. > | > | > | That's what I did initially, but I wasn't sure if that's > | > | > | acceptable because some optimisations will be gone, e.g. ==# 3.0 > | > | > | 3.0 will not rewrite to #1 (perhaps this isn't that bad, because > | > | > | comparing > | > | > | > | floating > | > | > | > | > | point numbers for equality isn't a good idea anyway). > | > | > | > | > | > | Janek > | > | > | > | > | > | > Simon > | > | > | > > | > | > | > | -----Original Message----- > | > | > | > | From: [email protected] > | > | > | > | [mailto:[email protected]] > | > | > | > | On Behalf Of Jan Stolarek > | > | > | > | Sent: 22 April 2013 13:48 > | > | > | > | To: [email protected] > | > | > | > | Subject: Handling of NaN > | > | > | > | > | > | > | > | I need some help with my work on ticket #6135. Consider this > | > | > | > | > | > | program: > | > | > | > | {-# LANGUAGE BangPatterns, MagicHash #-} module Main where > | > | > | > | > | > | > | > | import GHC.Exts > | > | > | > | > | > | > | > | main = print $ nan## ==## nan## > | > | > | > | where !(D# nan##) = 0.0 / 0.0 > | > | > | > | > | > | > | > | This prints False, which is a correct implementation of > | > | > | > | IEEE754 standard. However when I compile this with my > | > | > | > | modified compiler > | > | > | > | that > | > | > | > | > | > | uses new comparison primops (they return Int# instead of > | > | > | > | Bool) I get True, whcih obviously is incorrect. I belive > | > | > | > | that > | > | > | > | the > | > | > | > | > | > | problem lies in this piece of code from > | > | prelude/PrelRules.hs: > | > | > | > | mkRelOpRule :: Name -> (forall a . Ord a => a -> a -> Bool) > | > | > | > | -> [RuleM CoreExpr] -> Maybe CoreRule > | > | > | > | mkRelOpRule nm > | > | > | > | cmp > | > | > | > | > | > | extra > | > | > | > | = mkPrimOpRule nm 2 $ rules ++ extra > | > | > | > | where > | > | > | > | rules = [ binaryLit (\_ -> cmpOp cmp) > | > | > | > | , equalArgs >> > | > | > | > | -- x `cmp` x does not depend on x, so > | > | > | > | -- compute it for the arbitrary value 'True' > | > | > | > | -- and use that result > | > | > | > | return (if cmp True True > | > | > | > | then trueVal > | > | > | > | else falseVal) ] > | > | > | > | > | > | > | > | It looks that equalArgs suddenly started to return True, > | > | > | > | whereas > | > | > | > | it > | > | > | > | > | > | previously returned False. On the other hand in GHCi I get > | > | > | > | correct > | > | > | > | > | > | result (False). Can anyone give me a hint why is this > | > | happening? > | > | > | > | > | Janek > | > | > | > | > | > | > | > | _______________________________________________ > | > | > | > | ghc-devs mailing list > | > | > | > | [email protected] > | > | > | > | http://www.haskell.org/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
