dynamic ForeignLabel and DLLs

[Wolfgang Thaller]

> How do you know for a given foreign call whether it is dynamic or not?

I don't. The linker does, it removes the import stub if it is 
unnecessary. For data references, the imported pointer is replaced by a 
const_data pointer to the data, so an extra indirection stays, but I 
guess we can afford that.

> By all means adopt what's there, or add another form of labelDynamic
> which suits your situation better.  We don't want to throw away
> labelDynamic, even though it isn't used, because it imposes some
> requirements on the rest of the compiler that we don't want to forget
> about in case we ever revisit DLL support.

I added a new function that returns True whenever labelDynamic returns 
true (which I think it never does, currently), or when the label is a 
foreign label. Every foreign label *could* be imported from a DLL, so I 
have to do this.

I couldn't use deRefDLL because it's outside the NCG monad. I needed to 
call addImportNat to record which "dynamic linker stubs" I have to 
create.

The code I committed yesterday should work for the standard case where 
all the Haskell code is in the main executable, but at least some of 
the foreign code that it calls is in dynamic libraries. For real DLL 
support, I'd have to generate position independent code, which isn't 
that easy on PPC, as getting the current program counter/instruction 
pointer is relatively expensive (involves a fake subroutine call). It's 
OK to do it at the beginning of a top-level proc, but not for every 
data reference. I'd probably need some extra info from the codeGen to 
do this properly (like, "will this proc ever be called directly, or 
will it always be called via a computed goto?", "where will it be 
called from?" etc.). But this can wait, I won't tackle this right away, 
as it should be possible to generate DLL-capable code via C.

Cheers,

Wolfgang

P.S.: Adding a BaseReg on PowerPC _did_ reduce the code size noticably.