Re: [GHC] #8275: Loopification breaks profiling

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: highest | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: 8298 | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Comment (by jstolarek): Edward, there is some progress. There is a single test in the testsuite that fails when loopification is turned on, but works if it is off. That test is T1735. Assuming that you built GHC with profiling libraries you can run this test from `testsuite/tests` with: {{{ make WAY=normal EXTRA_HC_OPTS="-prof -fprof-auto -rtsopts" TEST=T1735 }}} and it should pass. Including `-floopification` on the list of extra options should make the test fail. Examining the Cmm dumps is a pain - they are over 200k lines - but I found a single place where loopification occurs. Attached are the dumps of this single function with and without loopification. `-input` suffix denotes code produced by the code generator, `-output` suffix denotes code after it has gone through all optimisations in Cmm pipeline. If you look at the output code you will notice one incorrect transformation in the loopified version: stack check gets duplicated and inserted at the end of function, right before making a tail call. There are two issues here: 1) Correctness. Cmm pipeline performs an incorrect transformation on a valid Cmm input program. It duplicates stack check at the end of a function, which violates assumption that stack checks are made only at the entry to a function (see !CmmLayoutStack, line 208). Putting stack check at the end makes it invalid, because we set required amount of stack to be a fixed value. As a result at the end of a function we are checking for more stack that we actually need (becuase we have moved the stack pointer). Simon proposes to fix that by referring to `` instead of `Sp` (before stack layout). To me it is not clear whether this stack check is direct cause of a segfault, though it certainly is not correct. 2) Performance. Putting stack check right before making a call makes no sense. This is probably the direct result of control flow optimisations pass, but there is a deeper problem here. When making a loopified tail call we want to avoid re-doing the stack check because it is not necessary to do it again, but we want to perform heap check. So loopified tail call should make a jump in between those two. Currently generation of stack and heap checks is closely coupled with each other in the code generator and it will probably take some work to separate them. Surprisingly, sometimes we get good code (loopification jumps between stack and heap checks) and sometimes we don't. Neither I nor Simon know why this happens - I need to look at the code and solve that mystery. I wasn't able to figure out one thing. The loopified tail call omits one block of code related to profiling (the one with magic numbers). I don't know whether this is correct or not. Edward, are you able to tell whether this can be done or not? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler