[GHC] #11731: Simplifier: Inlining trivial let can lose sharing
GHC
ghc-devs at haskell.org
Wed Mar 30 17:26:46 UTC 2016
#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
More information about the ghc-tickets
mailing list