Re: [GHC] #14626: No need to enter a scrutinised value

11 Jan 2018

      #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 :    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