[GHC] #16039: 'GHC.Magic.noinline <var>' should not float out

[GHC]

#16039: 'GHC.Magic.noinline <var>' should not float out
-------------------------------------+-------------------------------------
        Reporter:  heisenbug         |                Owner:  heisenbug
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.10.1
       Component:  Compiler          |              Version:  8.2.1
      Resolution:                    |             Keywords:  FloatOut
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #15155            |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by heisenbug):

 Replying to [comment:10 simonpj]:
 > > `exprIsCheapX` helped a lot
 >
 > What does that mean?  How did it help?

 There seem to be two distinct mechanisms to float out expressions to
 toplevel.
 After fixing `notWorthFloating` and `exprIsTrivial` (which took care of
 the float-out pass) still a bunch of expressions (e.g `noinline @ (Role ->
 Type -> MCoercionN -> Coercion) mkGReflCo`) that are destined for class
 dictionaries got floated out for no reason. After fixing `exprIsCheapX`
 this is not happening any more.

 >
 > Rather than doing this deep pattern matching during `exprIsCheapX`
 (which will happen repeatedly in an `App`-chain), I think it might be
 nicer (more efficient) to accumulate a list of (value) arguments instead
 of the `n` argument to `go`.
 >
 > >  Check out exprIsBig too.
 >
 > Maybe.  But concentrate on the places where we know it makes a
 difference.

 Sounds like a plan. I'll wrap up the changes that I have so far and work
 on more testcases. I think that it'll be okay to land this for 8.10.
 If you want to look at my changes, you'll find them in
 https://gitlab.haskell.org/ghc/ghc/commits/wip/T16039 .


 Then I'll scrutinise the code for similar problems in a low-prio follow-up
 ticket.

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