I've opened #13182 to explore one possible approach to dataToTag# that strikes me as likely to be simpler and to have fewer potential gotchas. But there could be critical points I'm missing about why we do it as we do now.

-------- Original message --------
From: Simon Peyton Jones <simonpj@microsoft.com>
Date: 1/23/17 4:47 PM (GMT-05:00)
To: David Feuer <david@well-typed.com>
Cc: ghc-devs@haskell.org
Subject: RE: Floating lazy primops

We should have this conversation on a ticket, perhaps #13027.

| good at the time). Are there actually any primops with lifted arguments
| where we *want* speculation? Perhaps the most important primop to
| consider is seq#, which is

I don't understand this question.  comment:23 of #13027 specifically says to skip the ok-for-spec test for lifted args. So you as "are the any" whereas comment:23 says "all".

| 2. If dataToTag# is marked can_fail (an aspect of https://
| phabricator.haskell.org/rGHC5a9a1738023a), is it still possible for it to
| end up being applied to an unevaluated argument? If not, perhaps the
| CorePrep specials can be removed altogether.

That may be true, but it's not easy to GUARANTEE in the way that Lint guarantees types.   So I'm happier leaving in the CorePrep stuff.. but please do add a comment there that points to the Note in primops.txt.pp and says that it seems unlikely this will ever occur.

| One more question: do you think it's *better* to let dataToTag# float and
| then fix it up later, or better to mark it can_fail? Unlike
| reallyUnsafePtrEquality#, dataToTag# is used all over the place, so it is
| important that it interacts as well as possible with the optimizer,
| whatever that entails.

I think better to do as now. That way the simplifier has the opportunity to common-up multiple evals into one.  If we add them later that's harder. 

By all means add Notes to explain this.

Thanks!

Simon


| -----Original Message-----
| From: David Feuer [mailto:david@well-typed.com]
| Sent: 18 January 2017 19:45
| To: Simon Peyton Jones <simonpj@microsoft.com>
| Cc: ghc-devs@haskell.org
| Subject: Floating lazy primops
|
| I opened up https://phabricator.haskell.org/D2987 to mark
| reallyUnsafePtrEquality# can_fail, but in the process I realized a couple
| things.
|
| 1. Part of https://phabricator.haskell.org/rGHC5a9a1738023a may actually
| not have been such a hot idea after all (although it certainly sounded
| good at the time). Are there actually any primops with lifted arguments
| where we *want* speculation? Perhaps the most important primop to
| consider is seq#, which is
| (mysteriously?) marked neither can_fail nor has_side_effects, but another
| to look at is unpackClosure#, which seems likely to give different
| results before and after forcing. Most other primops with lifted
| arguments are marked has_side_effects, and therefore won't be floated out
| anyway.
|
| 2. If dataToTag# is marked can_fail (an aspect of https://
| phabricator.haskell.org/rGHC5a9a1738023a), is it still possible for it to
| end up being applied to an unevaluated argument? If not, perhaps the
| CorePrep specials can be removed altogether.
|
| David Feuer