[GHC] #15155: How untagged pointers sneak into banged fields

[GHC]

#15155: How untagged pointers sneak into banged fields
-------------------------------------+-------------------------------------
        Reporter:  heisenbug         |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.4.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:  14677
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by heisenbug):

 Replying to [comment:1 simonpj]:
 > I'm lost in a maze of twisty passages.  We have

 Sorry, but this was how the story unfolded with time. Believe me, I am
 also starting to get lost. Will try to clarify the relations, to my best
 knowledge, below.

 >
 > * #14677 Code generator does not correctly tag a pointer.  I'm not sure
 if this is a serious bug, or just the loss of a potential optimisation.
 (I think the latter.)

 Performance-only bug. Leads to unnecessarily generated code and extra
 runtime because closures are entered redundantly.

 >
 > * #14626 No need to enter a scrutinised value.  Apparently blocked on
 #14677

 Does not seem to block #14373 but could make it more effective.

 >
 > * #14373 Introduce PTR-tagging for big constructor families.   This has
 Phab:D4267.  I think it may be blocked (in some way) on #15155.

 All the above is about making pointer tagging more expressive and reducing
 closure entries.

 The very bottom of this stack is

 * #13861 Take more advantage of STG representation invariance (follows up
 #9291)


 >
 > * #15155 (this ticket).
 >
 > I'm not sure how these tickets inter-relate beyond the blocking notes
 I've put here.  Which is most urgent?  Gabor, are you actively working on
 any of them?

 I think #15155 (this ticket) is the one that needs to be resolved first,
 so that #14677 can land. Then #14626 and #14373 can be resolved, unless
 new problems surface. #13861 has a proof-of-concept implementation, which
 will need some love, but with extended PTR-tagging (#14373) it'd cover
 more cases.

 Since I dreamed up the "conservative" solution just last night, I have no
 fix for this one yet, but could start with an implementation in early June
 latest. (In January I implemented intra-module "hardlinks" in the NCG.) I
 think it would be nice to have a discussion about `IND_STATIC` closures
 too, resp. their elimination.

 Overall I think it is worrisome that strict fields get initialised with
 non-tagged pointers, even if the compiler statically knows that the
 corresponding data is in WHNF.

 TL/DR: This is a stack of mostly dependent tickets (newer ones need to be
 resolved before older ones), each unlocking a new optimisation in its own
 right. Hopefully no more monsters lurking.

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