[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