#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