Christiaan
I’m totally paged out on this. Would you like to do this via a comment on !5562, giving a concrete example of a small program that doesn’t behave as you expect with your patch?
Sebastian may be able to help too.
Simon
From: ghc-devs <ghc-devs-bounces@haskell.org>
On Behalf Of Christiaan Baaij
Sent: 24 June 2021 10:56
To: ghc-devs <ghc-devs@haskell.org>
Subject: Is there a way to prevent reboxing in W/W (due to OPAQUE pragma proposal)
Hi Ghc-Devs,
I believe I've mostly finished the implementation of GHC proposal 0415 [1], the OPAQUE pragma, over at:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5562
The only remaining issue is that I'm unsure whether there's a way to prevent reboxing of worker arguments as witnessed here:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5562/diffs#29ad02619a9f318d67c6cd19648917dbb17354e9_0_134
Note that the reboxing doesn't happen in the worker of the OPAQUE-annotated bindings, because OPAQUE-annotated bindings aren't W/W-transformed, but in a worker of a function that calls the OPAQUE-annotated binding.
This reboxing was the reason behind the descision to W/W transform NOINLINE-annotated bindings in:
https://gitlab.haskell.org/ghc/ghc/-/commit/b572aadb20c2e41e2f6d7b48401bd0b4239ce9f8
But the whole idea behind OPAQUE is not to change calls to the annotated binding f by some call of a name-mangled version of f; so W/W transforming OPAQUE-annoted binders is not an option.
Any hints on how to avoid the reboxing (if possible) would be appreciated, like:
* Do I need to change something in GHC.Core.Opt.WorkWrap? or
* Do I need to change the demand/strictness signature of OPAQUE-annoted bindings?
* or something else?
Thanks,
Christiaan