[GHC] #16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 . round`

[GHC]

#16122: `round :: Double -> Int64` much slower than `fromIntegral @Int @Int64 .
round`
-------------------------------------+-------------------------------------
        Reporter:  Fuuzetsu          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.6.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 > It looks like user-defined rules are never applied to the RHS of other
 rules

 Hmm. You are right.  See `Note [Simplifying rules]` in `SimplUtils`.  So
 rules are switched off on both RHS and LHS of rules.

 But as noted above, built-in rules are not switched off.  In `Rules.hs` I
 see
 {{{
 matchRule dflags rule_env _is_active fn args _rough_args
           (BuiltinRule { ru_try = match_fn })
 -- Built-in rules can't be switched off, it seems
   = case match_fn dflags rule_env fn args of
         Nothing   -> Nothing
         Just expr -> Just expr
 }}}
 This seems wrong.  If we are going to switch off rules we should switch
 them all off.  We could just add
 {{{
 matchRule dflags rule_env _is_active fn args _rough_args
           (BuiltinRule { ru_try = match_fn })
   | not (is_active AlwaysActive)  -- Built-in rules are always active, but
   = Nothing                       -- sometimes we switch off rules
 altogether
                                   -- E.g. see SimplUtils.updModeForRules
   | otherwise
   = case match_fn dflags rule_env fn args of
         Nothing   -> Nothing
         Just expr -> Just expr
 }}}
 That still leaves the issue that two rules, a built-in one and a user-
 specified one, can be simultaneously active.  Which will win?  Well, it
 turns out that that user specified one does.  See this code in `Rules.hs`
 {{{
 isMoreSpecific :: CoreRule -> CoreRule -> Bool
 -- This tests if one rule is more specific than another
 -- We take the view that a BuiltinRule is less specific than
 -- anything else, because we want user-define rules to "win"
 -- In particular, class ops have a built-in rule, but we
 -- any user-specific rules to win
 --   eg (Trac #4397)
 --      truncate :: (RealFrac a, Integral b) => a -> b
 --      {-# RULES "truncate/Double->Int" truncate = double2Int #-}
 --      double2Int :: Double -> Int
 --   We want the specific RULE to beat the built-in class-op rule
 }}}
 I don't think this behaviour is documented in the user manual -- it should
 be.

 That would fix this ticket.  But in a rather delicate way: we rely on
 /not/ applying a built-in rule R1 to the RHS of another rule R2, in case
 when R2 fires there is a user-defined rule R3 that will beat R1.

 However, ignore built-in rules for the moment.  The `isMoreSpecfic` code
 above makes rule S1 "beat" rule S2 if S1 is more specific -- that is, if
 S1's LHS is a substitution instance of S2's.  (We should document this
 behaviour too.)  So consider
 {{{
 {-# RULES
   "S1" forall x. f [x]      = blah1
   "S2" forall y. f [Just y] = blah2
   "S3" forall z. h z        = f [z]
 #-}
 If we applied rules to the RHS of S3, only S1 would apply.  But if didn't
 (as happens now), and we had a term `h (Just 3)`, we'd rewrite it with S3
 to `f [Just 3]`, and now both S1 and S2 apply, and S2 would win.

 So this is a distinct reason, which we should add to `Note [Simplifying
 rules]`, for not applying rules to the RHS of rules.

 Would anyone like to write a patch for these fixes?
 * Make the above change to `matchRule`
 * Document the overlap behaviour of RULES in the user manual
 * Add the above reasoning to `Note [Simplifying rules]`

 Thanks!

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16122#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler