On 25/08/13 20:16, Jan Stolarek wrote:
We really want people to use the new primops, not the wrappers We do? Could you justify why we want to people to use primops?
What I meant was, if people are already using primops we want them to use the new ones instead.
Wrappers are equivalent to previous implementation of primops: previously we had call to tagToEnum# generated implicitly by the code generator, whereas now we have an explicit call to tagToEnum# in the source code of the wrappers.
Previously the tagToEnum# was optimised away in the code generator in the common cases. Perhaps the Simplifier will do that for the wrappers now, I don't know. But if people are using primops, they are probably deliberately writing low-level code and they don't want to be relying on optimisations that might not happen.
I don't see a reason why we might want to break people's code, except for maybe making them aware that there was some change in primops implementation. I think that from the beginning new primops were meant to be used in branchless algorithms - most people don't need that.
The new primops are what we should have used in the first place :-) They map more closely to the machine operations, and thus expose more detail to the compiler for optimisation. I've wanted to make this change for 15 years! I don't mind breaking these very low-level APIs. We could always provide a GHC.Prim.Compat for people who want to defer updating their code, we've done that kind of thing in the past (e.g. the Control.Exception migration). Cheers, Simon