Simon, I am worried that due to a wrong annotation here, a thunk is marked as single entry that is not really single entry, and I can imagine
#10744: Allow oneShot to work with unboxed types -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:9 nomeata]: that bad things can happen then. But if you think that this cannot happen, then I’d be relieved, and akio can go forwared using `oneShot`. Yes, this is what happened in #10414 and #10218. Suppose in my example in comment:8 that GHC does ''not'' float the `let x` thunk into the lambda for some reason. Then it might instead be marked single-entry. So we get {{{ f xs y = let x[single-entry] = expensive_fn y in map (oneShot (\v. x+v)) xs }}} The bad thing in #10414 and #10218 was that, with eager black-holing, `x` was blackholed, so that the second time it was entered we got `<<loop>>`. But the fix in ticket:10414#comment:29 switches off eager-blackholing for single-entry thunks, so it'll all be fine. So, because of that, I think we are good. Mind you, if we implement the sanity check in #10613, you might get failures reported due to bogus `oneShot` claims. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10744#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler