initial "foreign import prim" patches for review

[Simon Marlow]

On 09/06/2009 19:13, Duncan Coutts wrote:
> 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.

Yes, I think this is the right way to go.

foreign import prim "has_side_effects commutable foo#" :: ...

and then perhaps all the primops could be defined this way.  For the 
inline primops the code generator would have to spot them and generate 
inline code, but all knowledge of the out-of-line primops would be 
outside the compiler itself.  primops.txt.pp would go away, as would 
genprimopcode.  We get the curried wrappers for free, so no need for the 
PrimOpWrappers module.  GHC.Prim would be an ordinary module with source 
code.

As an intermediate step, we could just move the out-of-line primops out, 
leaving the inline ones defined in primops.txt.pp.  All of this is 
unforced of course, but I think it would be a nice cleanup.  On the 
other hand, it would mean that GHC.Prim becomes an interface file that 
GHC has to slurp on startup.

On the patches themselves:

  - I think we should drop the requirement for "unsafe", it doesn't
    have any meaning for primops

  - why are arguments required to be unboxed?

Otherwise, looks fine.

Cheers,
	Simon