[GHC] #14677: Code generator does not correctly tag a pointer

[GHC]

#14677: Code generator does not correctly tag a pointer
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.2
      Resolution:                    |             Keywords:  CodeGen
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:  15155             |             Blocking:  14626
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Great.  So I think we now agree that the IND_STATIC patch is about (a)
 code size  and (b) performance; and that both are very small (albeit
 worthwhile) improvements.  ''It is not about correctness''.  OK so far?

 When you say "your patch", what do you mean?

 When you say "incorrect behaviour" do you meant that we get a seg-fault?
 Or just that we enter a closure that could be properly tagged?  To be
 concrete, suppose we have
 {{{
 f x = case t of
         MkT (A a) -> case a of
                       I# y -> (I# (y +# 1) + x

 main = print (map f [1..1000])
 }}}
 In the code for the `case a` in `f`, we'll have a conditional that tests
 the tag-bits on `a`.  If they are 00 we'll enter `a`; and ''this path must
 exist'' in case we put a thunk in `MkT`; indeed `MkT` is not even strict
 in this case.

 However, we'd prefer not to take that code path, so it'd be better to put
 a correctly-tagged pointer into the `MkT`.  To do this we need your patch;
 and it must get exploited in two different places in the code generator.

 * When allocating a static closure, like in your example
 {{{
 t = MkT a
 }}}

 * When allocating a dynamic closure, like this:
 {{{
 data S = MkS Int A
 f x = ...(MkS x a)...
 }}}
   Here that `MkS x a` should get a correctly-tagged second field.

 It'd be good to ensure that you test both situations.

 Now it is much clearer.  If you could reflect the clarity in the Note,
 that would be good.

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