#11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2064 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Over at Phab you write
I still think this is the wrong approach.
but now I’m confused. Where did you say what’s wrong with this approach? This approach is my attempt to implement your suggestion “Perhaps we should simply refrain from inlining x under these circumstances” from comment:5! From this suggestion, we need to detect “these circumstances”, which requires us to detect that “The demand signature on y is marked "used- once"”. And this implies that looking at demand information. And this implies that we need to keep hold to it. Personally, I quite agree that the annotation should *not* be something we need to hold on to, although I don’t have a convincing solution, only the rough ideas above that boil down to systematically distinguishing between variables that guarantee to have sharing behavior and those where this is not guaranteed. Anyways, thanks for the explanation about `zapLamIdInfo`. It makes perfect sense when inlining a function into an expression. But do you agree that it should not be done to `f`’s definition? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11731#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler