[GSOC '15] Support for Haskell

[Jakub Zalewski]

Hi,

I am interested in developing Haskell support for PNaCl.

I wanted to get in touch with a prospective mentor to discuss the scope of this project.

From what I understood so far, PNaCl supports a subset of LLVM IR, so this project would focus on providing a back-end to GHC that will emit bitcode supported by PNaCl.

Best wishes,

-- Jakub

[Ben Smith]

Hi Jakub,

Thanks for your interest in porting Haskell to PNaCl!

You're correct, PNaCl supports a subset of LLVM IR. The PNaCl LLVM backend already has passes that lower IR generated by clang, but there are likely some different behaviors that are not currently supported (e.g. tail recursion guarantees). It's likely that some of Richard Diamond's work on a PNaCl Rust port will be similar here. See https://github.com/DiamondLovesYou/llvm and https://github.com/DiamondLovesYou/rust.

I'm guessing another significant chunk of work will be porting the Haskell runtime to PNaCl.

I'll be happy to discuss scope of this project with you, feel free to respond to this thread for now.

Thanks,

-Ben

[Jakub Zalewski]

Hi Ben,

Thank you for your reply.

I found that PNaCl only supports the ccc calling convention. I am not sure if that limitation is deliberate, but the LLVM IR emitted by GHC relies heavily on the GHC calling convention (also called calling convention 10). Would it be possible and within the scope of the project to add GHC calling convention to PNaCl?

Best wishes,

Jakub

[Jim Stichnoth]

Hi Jakub,

The PNaCl ABI simplification passes strip out the GHC calling convention attribute and replace everything with the C calling convention.  This simplifies the backend code generator and, like all such simplifications, reduces the attack surface.  If you needed to retain that attribute and disable the validation check against it, I expect it would be not too complicated.

First though, I would consider whether you can get by with the C calling convention.  As I understand it, the main reason for the GHC calling convention is performance.  But I also understand that PNaCl's backend code generator will need to be very aggressive about producing tail calls, to avoid stack overflows.

Jim

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to native-client-di...@googlegroups.com.
To post to this group, send email to native-cli...@googlegroups.com.
Visit this group at http://groups.google.com/group/native-client-discuss.
For more options, visit https://groups.google.com/d/optout.

[Jakub Zalewski]

Hi Jim,

Does PNaCl backend support LLVM's tail call optimisation? I am not sure how much PNaCl differs from a vanilla LLVM and I know that the current PNaCl bitcode will not allow to use LLVM's tail call optimisation, because LLVM's TCO does not work for C calling convention.

Also, I have some additional questions regarding the scope of the project.

- Would a native GHC that can target PNaCl be sufficient for the purpose of the project? Or would there be a need of GHCi running inside a browser (similar to the Lua interpreter in the PNaCl examples)?

- I guess a Pepper API wrapper for Haskell would be good, at least as an optional goal, or further development.

- How is PNaCl POSIX-compliance and its support for threading? Are there any notable differences/limitations?

Best wishes,

-- Jakub

[Jim Stichnoth]

Hi Jakub,

The PNaCl backend (pnacl-llc) is pretty much the same as the standard LLVM backend (llc), but with sandboxing restrictions.  These include bundling requirements, forcing bundle-aligned jump/call/ret targets, and sometimes sandboxed memory accesses.  These requirements generally don't affect the calling convention.  On top of that, the higher-level PNaCl bitcode ABI restricts bitcode to the C calling convention, removes varargs, and removes struct args and other arg types other than i{8,16,32,64} and f{32,64} and the PNaCl vector types.

When you apply all these restrictions and let the dust settle, you should find that "sibling call" or "sibcall" should still be generally amenable to tailcall lowering.  (I haven't actually tested this, but it should be fairly simple to construct small test cases and test across different target architectures and optimization levels by inspecting the assembly code.)

I think part of this project would involve changing the ghc-generated calls as necessary to ensure tailcall optimization in the backend.

Jim

[J Ho]

Ben, Jakub - as I was researching Haskell web building / GUI approaches this has naturally led me to the native client. Since this was supposed to be a part of Google summer of code I was just wondering whether you made this part of the project and if any progress has been made? There are some ideas about how to build a robust and powerfull Haskell web framework (e.g., this post) and knowing Haskell support for PNaCl is on the roadmap would be extremely exciting. Thank you!

On Monday, March 23, 2015 at 10:04:26 PM UTC+1, Ben Smith wrote:

[Jakub Zalewski]

Hi J, 

thanks for showing interest and enthusiasm in this gsoc project. 

In my gsoc proposal I focused mostly on the technical aspects of GHC: the possibility of connecting GHC's LLVM back-end to pnacl toolchain. 

Currently, I am still working on porting GHC's runtime system to clang-nacl toolchain as GHC depends on some things that are not currently available in native client's newlib toolchains. 

Best wishes,

Jakub

--
You received this message because you are subscribed to a topic in the Google Groups "Native-Client-Discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/native-client-discuss/uxdobdjDz1I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to native-client-di...@googlegroups.com.