[GHC] #13996: Non-cheap primop is duplicated

[GHC]

#13996: Non-cheap primop is duplicated
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      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’s a cost-model thing.  GHC finds that the call to `sin` amounts to a
 single call to the primop `sinDouble#`.  Is that cheap?  If so, better to
 push it inside the inner lambda, so the two lambdas come together
 (generally a big win).  E.g. if it was a single ‘add’ instruction,
 definitely better to push it inside.

 Look at `PrimOp.primOpIsCheap`; you’ll see that “cheapness” is
 approximated by

 * no side effects
 * cant fail
 * is a single instruction (i.e not a call to an out-of-line run-time
 system procedure)

 These three properties are set in `prelude/primops.txt.pp`

 Alas, `sinDouble#` satisfies all three things so it’s regarded as cheap.
 As Joachim says this may just be the wrong cost model for you.

 What to do?

 * Mitigate: `-fno-lambda-eta-expansion`

 * Hack to make `sin` look expensive: in `primops.txt.pp` set `can_fail` to
 true. This isn't true, but it's always safe.  It'll have other minor
 effects on optimising `sin` but I doubt it'll matter.

 * The Right Thing: add a `is_expensive` property for each primop and set
 it in `primops.txt.pp`. That's a bit more work, but it lets us say what we
 want.

 I don't feel strongly about which path to take.

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