Floating lazy primops

[David Feuer]

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.

On Wednesday, January 18, 2017 2:45:04 PM EST David Feuer wrote:
> 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs