The problem is that stg is too strongly typed

It’s not really typed, or at least only in a very half-hearted way.  To be 
concrete I think you can just use Any for any Pointer arg.   All STG needs to 
know, really, is which things are pointers.  Detailed type info like “are you a 
Char or a Bool” is strictly jam; indeed never used I think.  (I could be wrong 
but I’m pretty sure I’m not wrong in a fundamental way.

SImon

From: Johan Tibell [mailto:[email protected]]
Sent: 09 September 2015 23:22
To: Simon Peyton Jones; Simon Marlow; [email protected]
Subject: Converting unboxed sum types in StgCmm

Hi!

The original idea for implementing the backend part of the unboxed sums 
proposal was to convert from the core representation to the actual data 
representation (i.e. a tag followed by some pointer and non-pointer fields) in 
the unarise 
stg-to-stg<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fghc%2fghc%2fblob%2fmaster%2fcompiler%2fsimplStg%2fUnariseStg.hs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cca7beffb01494517d75108d2b9652973%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=U%2bFUNsL87iEemajTnAW9SxD9N5b4%2bG8QB1q19%2fX%2bBI4%3d>
 pass.

I have now realized that this won't work. The problem is that stg is too 
strongly typed. When we "desugar" sum types we need to convert functions 
receiving a value e.g. from

    f :: (# Bool | Char #) -> ...

to

    f :: NonPointer {-# tag#-} -> Pointer {-# Bool or Char #-} -> ...

Since stg is still typed with normal Haskell types (e.g. Bool, Char, etc), this 
is not possible, as we cannot represent an argument which has two different 
types.

It seems to me that we will have to do the conversion in the 
stg-to-cmm<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fghc%2fghc%2fblob%2fmaster%2fcompiler%2fcodeGen%2fStgCmm.hs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7cca7beffb01494517d75108d2b9652973%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=aXKZ78eGNKbJ6eZkxZgyJHgsAXpgOBjg3Zvqj%2bq7pk0%3d>
 pass, which is quite a bit more involved. For example, StgCmmEnv.idToReg 
function will have to change from

    idToReg :: DynFlags -> NonVoid Id -> LocalReg

to

    idToReg :: DynFlags -> NonVoid Id -> [LocalReg]

to accommodate the fact that we might need more than one register to store a 
binder.

Any ideas for a better solution?

-- Johan

_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Reply via email to