[GHC] #7307: Share top-level code for strings

[GHC]

#7307: Share top-level code for strings
-------------------------------------+------------------------------------
        Reporter:  simonpj           |            Owner:  parcs
            Type:  bug               |           Status:  new
        Priority:  normal            |        Milestone:  7.8.1
       Component:  Compiler          |          Version:  7.6.1
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by ezyang):

 Yeah, this code is buggy. Here are the problems I can find from a quick
 pass:

 * TOP_UNPACK is declared to have a thunk-representation. In that case, it
 needs to use a `StgThunkHeader`, so that the extra padding required to
 allow for lock-less thunk update in multithreaded code.

 * Similarly, it should be given the THU and SRT flags. Since these thunks
 are emitted into the data section (i.e. are static data), they also need
 the static flag (like THUNK_STATIC). So really TOP_UNPACK is a bad name.

 * I am not sure this is a good idea, but it seems like this mechanism
 could be generalized to variadic THUNK_STATICs, which are essentially
 THUNK_STATIC but have some payload attached to the end. You don't even
 have to hard-code the infotable anymore.

 * The GC code is wrong; TOP_UNPACK should be handled like a THUNK_STATIC.

 * I know for a fact you're missing this case from a number of other giant
 switch statements in the RTS. Do a grep.

 * The generated info table never pushes an update frame to adjust itself.
 So what happens when a reference to a TOP_UNPACK is inside generated code?
 I think you will end up repeatedly unpacking the string, though I am not
 100% sure here.

 * As for whether or not your C-- is right, you should double-check it with
 the old C-- we were generating for handling unpacking per thunk.

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