On Tue, 2009-06-09 at 16:32 +0100, Duncan Coutts wrote: > In particular I'd like to get feedback on the choice of representation > in the Core and STG layers. > > In the current patches I use the existing FCall/ForeignCall stuff for > the imported prim functions. I did this rather than trying to add > user-imported prim functions to the PrimOp type because it's pretty > wired in that PrimOp is a simple enumeration. An alternative to what > I've got now might be to unify PrimOp with these extra PrimCall things > (ie have a type containing either), or to make a third kind of IdDetail > in addition to the exiting PrimOpId and FCallId. > > The reason that longer term we might not want to stick with using > FCall/ForeignCall is that, as I understand it, after some backend > changes the primop and Haskell function cmm level calling conventions > will be unified and then the foreign import primop could be used at > almost any Haskell function type, not just simple unlifed args and > result.
Another reason we might want to treat them as primops in the Core level is that otherwise we loose the information about primops being commutable, being (not) able to fail, and the "needs_wrapper" business. Loosing these things may affect performance because the optimiser has less information. For the "foreign import prim" syntax we could provide this info via the import string, like we do the dynamic/wrapper/& stuff with C imports. eg: foreign import prim "can_fail divModInteger" :: Int# -> ByteArray# -> Int# -> ByteArray# -> (# Int#, ByteArray#, Int#, ByteArray# #) but internally it means we probably have to have some type that unifies genuine PrimOps with user-defined imported out-of-line cmm calls. Duncan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
