Re: [GHC] #14211: Compiler is unable to INLINE as well as the programmer can manually

21 Sep 2017

      #14211: Compiler is unable to INLINE as well as the programmer can manually
-------------------------------------+-------------------------------------
        Reporter:  harendra          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
      Resolution:                    |             Keywords:
                                     |  StaticArgumentTransformation,
                                     |  Inlining
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by mpickering):

 The reproducible example is in this github repo https://github.com
 /harendra-kumar/ghc-perf/tree/inlining-issue in the `inlining-issue`
 branch.

 You can compile it with `cabal new-build all` and then run the benchmark.

 The interesting point is the definition of `bindWith` which is a self-
 recursive function with 2 static arguments.

 Harendra observes that by "manually inlining" it, ie replacing the
 arguments with the statically known values produces much faster code than
 GHC produces on its own.

 I then observe that

 1. Removing the `INLINE` pragma and turning on `-fstatic-argument-
 transformation` has the same effect.
 2. The `INLINE` (or `INLINABLE`) pragma inhibits `-fstatic-argument-
 transformation` by creating a mutually recursive group (see
 https://mail.haskell.org/pipermail/ghc-devs/2017-September/014672.html).
 3. However, there is no way to make sure the optimised satted unfolding
 for `bindWith` is exposed so it can be inlined across modules (hence the
 comment about `-fexpose-all-unfoldings`).

 Harendra then has two questions about how this information should be
 communicated to users.

 1. Whether the `INLINE` section should mention about SAT.
 2. Whether we have a warning option which warns the programmer about
 missed inlining. This is only communicated by running `-dcore-lint`
 currently.

 Does that clear things up?

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14211#comment:8
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler