#14626: No need to enter a scrutinised value -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13861 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:14 simonpj]:
Name.hs:111 is a strict record field BTW. Does this ring a bell? Why is it OtherCon _ <- idUnfolding id but not tagged? Is it possibly implicitly unpacked?
Can you explain more? I can't make sense of this paragraph. What is "it" that might be implicitly unpacked? What does it mean to be "implicitly unpacked" ?
No, this is a red herring. Just me, desperately looking for hints. The `n_occ` is not unpacked. But I have a theory now. I set a few breakpoints: {{{ (gdb) info breakpoints Num Type Disp Enb Address What 8 breakpoint keep n 0x00007ffff52e39e0 in ghc_Name_nzuocC_info at compiler/basicTypes/Name.hs:111 breakpoint already hit 1 time 11 breakpoint keep y 0x00007ffff52e3a18 in ghc_Name_nzuocC_info at compiler/basicTypes/Name.hs:111 breakpoint already hit 46 times 12 breakpoint keep y 0x00007ffff2332a58 <checkTagged> breakpoint already hit 1 time }}} ''bp11'' is set as `breakpoint *ghc_Name_nzuocC_info+56` ''bp11'' is the continuation of ''bp8'' which is jumped at when the `Name` is in WHNF. Then the `n_occ` field is being extracted. It turns out that ''bp11'' needs to be hit '''46 times''' in order to find it untagged! Then I looked into why it is untagged at all. Here is a transcript from `gdb` `0x420006f4a9` is the (tagged) `Name`: {{{ (gdb) x/x 0x420006f4a9-1 0x420006f4a8: 0xf52ece08 (gdb) x/x 0x420006f4a9+7 0x420006f4b0: 0x0006f451 (gdb) x/x 0x420006f4a9+15 0x420006f4b8: 0x000662a0 (gdb) x/x 0x420006f4a9+19 0x420006f4bc: 0x00000042 ### the `n_occ` field is 0x42000662a0 (gdb) x/x 0x420006f4a9+23 0x420006f4c0: 0xf74a17e8 (gdb) x/x 0x420006f4a9+31 0x420006f4c8: 0x00001818 }}} Then I follow the closure pointer of the `OccName`: {{{ (gdb) x/2x 0x42000662a0 0x42000662a0: 0xf2335878 0x00007fff (gdb) x/x 0x00007ffff2335878 0x7ffff2335878 <stg_BLACKHOLE_info>: 0x08438b48 }}} Ooops! How can a strict field point to a '''BLACKHOLE'''? So this is my findings. Are strict fields able to hold blackholes? And if so, why do they carry an ''isEvaldUnfolding` when pattern matched against? Any hints appreciated!
One good thing would be to distill a tiny example, and it sounds as if
you have enough insight to do that now. E.g. perhaps you are saying that
{{{ data T = MkT ![Int] f (MkT xs) = xs }}} returns a badly-tagged pointer? If so, just compile that tiny program and see. etc.
-- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14626#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler