#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: | Blocked By: | Related Tickets: ----------------------------------------+---------------------------------- Changes (by ezyang): * priority: high => highest -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Loopification triggers for fully-saturated (but not over-saturated!) tail calls. So in this code: {{{ f 0 = 4 f 1 = 5 f n = case f (n - 2) of 4 -> 4 5 -> f (n - 1) }}} If will trigger for call to `f (n - 1)` in second branch of case, but will not trigger for `f (n - 2)` in case scrutinee. I checked and this code actually causes segfault when compiled with `-prof -fprof-auto -rtsopts` (assuming you add `main = print (f 5)` in the file), but it only happens when `f :: Integer -> Integer` and not when `f :: Int -> Int`, so I suspect that the bug might actually be hidden somewhere in the libraries and I might be looking at wrong code. The idea behind the loopification is that it should put parameters in the local variables (instead of global registers) and make a jump (instead of call). `f` function begins like this in Cmm: {{{ cYp: _sUP::P64 = R2; _sUO::P64 = R1; if (%MO_UU_Conv_W32_W64(I32[era]) <= 0) goto cW1; else goto cVZ; cVZ: I64[R1 + 15] = I64[R1 + 15] & 1152921503533105152 | %MO_UU_Conv_W32_W64(I32[era]) | 1152921504606846976; goto cW1; cW1: if (Sp - 104 < SpLim) goto cYq; else goto cYr; cYr: Hp = Hp + 40; if (Hp > HpLim) goto cYt; else goto cYs }}} Without loopification tail call will be a normal call: {{{ cYM: I64[CCCS + 72] = I64[CCCS + 72] + %MO_UU_Conv_W64_W64(6 - 2); I64[Hp - 40] = sat_sVa_info; I64[Hp - 32] = CCCS; I64[Hp - 24] = (%MO_UU_Conv_W32_W64(I32[era]) << 30) | 0; P64[Hp - 8] = _sUN::P64; P64[Hp] = _sUP::P64; _cXT::P64 = Hp - 40; R2 = _cXT::P64; R1 = _sUO::P64; Sp = Sp + 40; call f1_sUQ_info(R2, R1) args: 8, res: 0, upd: 8; }}} With loopification we get: {{{ cYM: I64[CCCS + 72] = I64[CCCS + 72] + %MO_UU_Conv_W64_W64(6 - 2); I64[Hp - 40] = sat_sV8_info; I64[Hp - 32] = CCCS; I64[Hp - 24] = (%MO_UU_Conv_W32_W64(I32[era]) << 30) | 0; P64[Hp - 8] = _sUL::P64; P64[Hp] = _sUP::P64; _cXT::P64 = Hp - 40; _sUP::P64 = _cXT::P64; goto cW2; cW2: if (Sp - 104 < SpLim) goto uZq; else goto uZp; uZq: Sp = Sp + 40; goto cYq; cYq: R2 = _sUP::P64; R1 = _sUO::P64; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; uZp: Sp = Sp + 40; goto cYr; }}} What might be surprising is that value of `_sUO` is not set before making tail call, but that *seems* to be OK - it is only shuffled between the stack and local variable. Note also that loopified call doesn't jump directly to second label `cVZ`, but instead it jumps to `cYr`. In principle this is OK (we want to skip stack check but not heap check), but TBH I can't tell whether in this case that is correct - I don't know what the magical numbers in `cVZ` do. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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): Another thing I observed is that my example is very sensitive. If you modify it by removing any call to `f` (for example by changing scrutinee to `case n of...` or second branch to `5 -> 5`) or replace second pattern match in case alternatives with `_` (i.e second branch becomes `_ -> f (n - 1)`) the segfault disappears. I haven't yet examined the differences in Cmm between these versions, but if the problem is caused by code generated for `f` this should allow us to track the cause. I don't know yet how to debug this issue if the problem is hidden in the libraries :-/ -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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, I disabled loopification by default - this should allow you to use profiling. I noticed that enabling loopification for my test program does not trigger segfault. So the problem was in the libraries, not in code snippet that I uploaded here. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#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

#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): Replying to [comment:12 ezyang]:

As for whether or not the LDV code needs to be done again, it depends on whether node (R1) changes when looping. Yes, R1 does change inside the loop.

the loop-back needs to insert a heap check for preemption purposes. And if a loop can be preempted, then the era can change, and yes, you need to run the LDV check after the preemption. I don't fully understand this. What is preemption? If upon entry to the loop I will do the LDV code and heap check, will this ensure correctnes of profiling and `-falways-yields`? Is this described on the wiki somewhere (preemption and LDV)?

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

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: 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): I actually already implemented 1), but the implementation is only a proof- of-concept. It's available [https://github.com/jstolarek/ghc/commit/66d5598bc1163c32267c55670c579d93cce9... here], but it need testing, cleanup (we can just drop sp_high and use final_hwn instead and perhaps entry_args are not used anymore?) and improving `constantFoldMachOpM` in `CmmOpt`, so that `if ((Sp + 56) - 96 < SpLim) goto u4yi; else goto u4yh;` gets constant folded properly. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 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: ----------------------------------------+---------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 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 Jan Stolarek ): In [changeset:"94125c97e49987e91fa54da6c86bc6d17417f5cf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="94125c97e49987e91fa54da6c86bc6d17417f5cf" Generate (old + 0) instead of Sp in stack checks When compiling a function we can determine how much stack space it will use. We therefore need to perform only a single stack check at the beginning of a function to see if we have enough stack space. Instead of referring directly to Sp - as we used to do in the past - the code generator uses (old + 0) in the stack check. Stack layout phase turns (old + 0) into Sp. The idea here is that, while we need to perform only one stack check for each function, we could in theory place more stack checks later in the function. They would be redundant, but not incorrect (in a sense that they should not change program behaviour). We need to make sure however that a stack check inserted after incrementing the stack pointer checks for a respectively smaller stack space. This would not be the case if the code generator produced direct references to Sp. By referencing (old + 0) we make sure that we always check for a correct amount of stack: when converting (old + 0) to Sp the stack layout phase takes into account changes already made to stack pointer. The idea for this change came from observations made while debugging #8275. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: 7.8.1 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): I believe I know the reason for duplicating the stack check. There is at least one bug in !CmmContFlowOpt module. Consider this: {{{ L1: goto L2 L2: whatever L3: goto L1 }}} We are processing blocks from the end. When we reach L3 first guard in `maybe_concat` function (!CmmContFlowOpt.hs, line 123) will turn that blocks into: {{{ L1: goto L2 L2: whatever L3: goto L2 }}} However, the number of predecessors of L2 block is not updated because `backEdges` is computed once before we run `maybe_concat` and is not updated when we make changes to the block structure. Another issue, which I have not yet encountered but I believe may arise as well, comes from the fact that we may map one label to a different one, but again we don't that take into account when determining the number of predecessors. I wrote a fix for that sometime in July, but I did not merged into HEAD - I guess I'll do that now. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: 7.8.1 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: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by simonpj): It's absolutely right to refer to `(old+0)`. But I don't understand the patch (in comment 19), to `CmmLayoutStack`. The change made there is simply to ''pass a different (larger) value to `manifestSp`''. And that's the only change to that module. So we'll generate different, wrong code. I don't see how this can possibly work. And yet apparently it does. What am I missing? (The change to `StgCmmHeap` is different, and is fine.) Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: 7.8.1 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: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by jstolarek): Replying to [comment:24 simonpj]:

But I don't understand the patch (in comment 19), to `CmmLayoutStack`. The change made there is simply to ''pass a different (larger) value to `manifestSp`''. And that's the only change to that module. So we'll generate different, wrong code. I don't see how this can possibly work. And yet apparently it does. What am I missing?

I'll try to explain this with an example of function that uses no stack space. Previously we generated stack checks that looked like this: {{{ if (Sp - <highSp> < SpLim) ... }}} If the function used no stack, then stack layout (`areaToSp` function, second guard) transformed this into: {{{ if (Sp - 0 < SpLim) ... }}} This check is always false and it used to be eliminated by the third guard in `areaToSp`. The value of `<highSp>` is computed to be `0` by the line of code that I removed in !CmmLayoutStack. Now consider new version. Code generator gives us: {{{ if ((old + 0) - <highSp> < SpLim) ... }}} As you pointed out, `<highSp>` will now be larger. But `(old + 0)` will not be `Sp`! This check will be turned into something this: {{{ if ((Sp + 8) - 8 < SpLim) ... }}} That is the reason why the elimination of always false stack checks was killed by my change. BTW. Simon, you wrote the code for that patch when I was in Cambridge :-) Do you remember how we (well, mostly you) updated [http://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/StackAreas this wiki page] and how we were confused with addressing offsets into an `Old` area? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: new Priority: high | Milestone: 7.8.1 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: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by simonpj): Yes, that makes sense thank you. I was forgetting about the late-bound constant `CmmHighStackMark`, which `manifestSp` manifests along with the areas etc. I've added yet more comments! Disappointing that you still get the seg fault. I hope you make progress in tracking it down. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 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: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by simonmar): Replying to [comment:26 jstolarek]:

BTW. Simon, you wrote the code for that patch when I was in Cambridge :-) Do you remember how we (well, mostly you) updated [http://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/StackAreas this wiki page] and how we were confused with addressing offsets into an `Old` area?

I am afraid that wiki page was not updated when I rewrote the stack layout algorithm, and it's woefully out of date. In particular there are no `RegSlots` any more. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.8.1 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: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by jstolarek): Thanks Patrick! Currently I'm without my main laptop so I can't verify your patch - I will do it in Wednesday, unless someone else can do it before. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:33 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: patch Priority: high | Milestone: 7.8.1 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: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Changes (by jstolarek): * owner: => jstolarek Comment: OK, I got my laptop back :-) Patch validates, but before I push it I want to make a few more tests to see that it does the right thing.

And here's an ugly PoC patch that moves the self-loop label below the stack check:

Could you explain how and why this works? I mostly interested in knowing how does it guarantee to place self-loop label after stack check but before heap check. I don't have more time to investigate this at the moment but if the patch is ready and working it would be good to have it pushed. Once I push your patch for loopification I'll close this ticket and start a new one for moving self-loop label after the stack check. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:35 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Changes (by jstolarek): * status: patch => closed * resolution: => fixed Comment: OK, I see how the loopification patch works. Previously we had: {{{ c4AC: call "ccall" arg hints: [PtrHint, PtrHint] result hints: [] enterFunCCS(BaseReg, I64[R1 - 1 + 8]); }}} Now we have: {{{ c4AC: call "ccall" arg hints: [PtrHint, PtrHint] result hints: [] enterFunCCS(BaseReg, I64[_s2UW::P64 - 1 + 8]); }}} The `_s2UW::P64` is declared anyway so no extra work required :-) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:37 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: jstolarek Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Jan Stolarek ): In [changeset:"6d24076be9aff562cd449aa1d39b8eb14638bcd6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6d24076be9aff562cd449aa1d39b8eb14638bcd6" Document solution to #8275 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:39 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 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: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Comment (by Patrick Palka ): In [changeset:"ac31b79924e9330c577ea63af9b0f10f4fc6c8f6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ac31b79924e9330c577ea63af9b0f10f4fc6c8f6" Move the LDV code below the self-loop label (#8275) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:41 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8275: Loopification breaks profiling ----------------------------------------+---------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.8.1 Component: Profiling | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC failed | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: 8456 | Related Tickets: ----------------------------------------+---------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Ok, looks good, thanks. I'll re-open if I find any problems. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8275#comment:43 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler