[GHC] #11731: Simplifier: Inlining trivial let can lose sharing
GHC
ghc-devs at haskell.org
Tue Mar 22 14:59:53 UTC 2016
#11731: Simplifier: Inlining trivial let can lose sharing
-------------------------------------+-------------------------------------
Reporter: nomeata | Owner:
Type: bug | Status: new
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):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by nomeata):
So you suggest that the desired semantics is that a trivial `let` should
guarantee sharing, right?
In this case, transforming `let x = y in foo x` to `foo y` is not a valid
transformation any more. Unless we can guarantee that `foo y` evaluates
`y` only once ''or'' unless we can guarantee that `y` is shared anyways.
Assuming we do not want to drag strictness annotations into the semantics,
we cannot do that! (But maybe dragging them in is fine?)
The rule “a trivial `let` does not guarantee sharing” allows the the above
transformation unconditionally, but shifts the onus to the earlier
simplification of the RHS. Is that less hairy there? Not sure...
Or maybe, as a third option, we should flag a variable with a bit of
information that indicates whether it is shared (and safe to evaluate
multiple times). How is that different from the demand annotation? The
demand annotation says something about how it ''is'' used, while this flag
contains information about how the variable is going to be created (with
or without an update frame) and then guides how it ''can'' be used. I
don’t see all the consequences, of course, but such a variable would in
many cases behave more like a possibly costly expression, i.e. should not
be duped, not be floated into a let etc.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11731#comment:13>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list