CLabel.RtsLabel wants a Module parameter

[Simon Peyton-Jones]

| To make Windows DLLs work again, I think I want to change cmm/CLabel to
| carry real module/package ids. Doing so looks like a lot of work, so I
| thought I'd run it by people before starting..
| 
| My problem is that when compiling
| libraries/integer-gmp/cbits/gmp-wrappers.cmm, all labels defined in this
| source file are treated as belonging to the runtime system, instead of
| the integer-gmp library. This happens directly in the Cmm parser. For
| instance, when parsing procs at CmmParse.y:246, the label which names
| the proc is created by (mkRtsCodeLabelFS $1). This creates a  RtsLabel
| (RtsCodeFS $1)  where  RtsCodeFS is a constructor of RtsLabelInfo.
| 
| When compiling integer-gmp into a DLL, we need to know whether a given
| symbol is in the local package/DLL, or in an external one. At the
| moment, it thinks that ALL symbols from gmp-wrappers.cmm are in the DLL
| for the runtime system, so generates the wrong code.
| 
| My proposed solution is to add a Module parameter to CmmLabel.RtsLabel
| so we have:
| 
| data CLabel = ... | RtsLabel Module RtsLabelInfo | ...

I think this looks fine.  Compare the IdLabel constructor which goes
	data CLabel = ...| IdLabel Name CafInfo IdLabelInfo | ...
A Name contains a Module and an OccName, so the net effect is similar to what you propose.

Definitely combine those FS things.  Indeed, I might go further.  Maybe you should have

	CmmLabel Module FastString CmmLabelInfo

I've renamed 'Rts' to 'Cmm' (because it's not an RTS thing at all; rather a .cmm file).  More important, I suggest pulling the FastString out of the RtsLabelInfo into the constructor, which seems more reasonable (cf IdLabel).  Then the CmmLabelInfo gives the suffix of the label, just as the IdLabelInfo does. 

For things like RtsSelectorEntry, the string would then have to be "stg_sel" which would arguably add an extra rather redundant field to the CmmLabel.  If we cared enough, we could retain RtsLabel for things which have baked-in names and definitely come from the RTS.

Then for the most part we'd have
	IdLabel    for things arising from .hs files associated with an Id
	CmmLablel  for things arising from .cmm files, or not associated with an Id

It seems to me that there are way too many constructors in CLabel.  
In general I don't understand the criterion for choosing whether to
	- use a new CLabel constructor
	- or just say (CmmLabel mod str)
Example: ModuleRegdLable, HpcModuleLabel

The main reason that CLabel has structure is so that we can support predicates over them (eg isCFunctionLabel) and transform them (infoLblToEntryLbl).

We don't need to solve all this in one go, though.
I don't think this'll take 3 days!

Simon


| 
| ... then when I'm spending the next 3 days of my life in refactoring
| pergatory I'll also merge Rts* with Rts*FS in RtsLabelInfo, which seems
| to be begging for it.
| 
| We could also change the names "RtsLabel" and "RtsLabelInfo" to
| something less RTS specific, (maybe CmmLabel and CmmLabelInfo?)
| 
| Does this sound like a good idea, or is there a better way of doing it?
| 
| Thanks,
| Ben.
| 
| 
| _______________________________________________
| Cvs-ghc mailing list
| Cvs-ghc at haskell.org
| http://www.haskell.org/mailman/listinfo/cvs-ghc