[GHC] #8793: Improve GHC.Event.IntTable performance

[GHC]

#8793: Improve GHC.Event.IntTable performance
-------------------------------------+-------------------------------------
        Reporter:  cdk               |                Owner:
            Type:  task              |               Status:  patch
        Priority:  normal            |            Milestone:  8.0.1
       Component:  Core Libraries    |              Version:  7.6.3
      Resolution:                    |             Keywords:
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 jscholl):

 > Interesting, though I don't yet understand the details.  Could you boil
 out a standalone example that demonstrates just this single issue?  I.e.
 two versions of a function, one of which repeats the stack check and one
 of which doesn't, and show the code side by side?

 If I understand cmm correctly, we jump to the start of $wa in line 34, so
 the IO version repeats the stack check. The corresponding instruction in
 the pure version is in line 33, here we jump to cCT, so behind our stack
 check. This should also be possible in the IO version as the function only
 uses constant stack space and if it was available once, it should stay
 available until we deallocate it, right?

 > > but it seems hard or impossible to correctly identity such unused
 arguments (I mean, it is used, but only in a function which does not use
 it...).
 >
 > Well GHC's strictness analyser should find exactly this case. I'm
 puzzled why it does not.  Again, could you spare a moment to make a
 standalone reproducer for just this issue?  Or at least a smallish
 function I can compile in isolation to see this argument not disappearing.
 >

 No, I did not mean the optimizer in this case. The unused argument is
 optimized out, I was just thinking whether GHC could warn if an argument
 is never used (as it does with unused variables), as this sometimes
 indicated unfinished code which should either be removed (or documented as
 such) or finished. But I think this comes with too many cases where you
 want an unused argument, either to pass in a type via proxy or to satisfy
 another functions expectations. And if a function is recursive, unused
 arguments have to be passed on.

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