Skip to content

[WASM] Add minimal support for targeting wasm32-unknown-unknown-wasm. Forked #20684 #27860

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

kateinoigakukun
Copy link
Member

@kateinoigakukun kateinoigakukun commented Oct 24, 2019

This PR is based on #20684 which adds the minimal wasm support.

And I added some test case to ensure that swiftc accepts wasm32-unknown-unknown-wasm and wasm64-unknown-unknown-wasm.

This is my first time to write lit test case, so please let me know if there is a problem.

@kateinoigakukun kateinoigakukun force-pushed the katei/swasm-minimal-triple-support branch from 44979cd to 4f69a8d Compare October 24, 2019 14:23
@karwa
Copy link
Contributor

karwa commented Nov 29, 2019

In the time since the precursor to this PR was opened, our fork of LLVM has advanced enough to the point that it supports wasi. Rather than trying to support a "none" OS, why don't we switch to supporting the wasi triples (wasm32-wasi and wasm64-wasi) instead? That would seem to address @compnerd 's issues.

In platform-specific code, that's what you're going to be interested in, anyway:

#if os(wasi)
import WasiLibc // wasi's stripped-down libc

printf(...)

#endif

ddunbar and others added 3 commits December 3, 2019 06:31
 - This is nothing beyond preventing the compiler from rejecting this target
   triple.

 - There doesn't yet appear to be a well-defined convention around a triple
   which detects WASM based on an "OS" field, so we use the "wasm" indicator in
   the environment component.
@kateinoigakukun kateinoigakukun force-pushed the katei/swasm-minimal-triple-support branch 3 times, most recently from 73980a7 to 3117991 Compare December 3, 2019 06:44
@kateinoigakukun kateinoigakukun force-pushed the katei/swasm-minimal-triple-support branch from 3117991 to 4f82512 Compare December 3, 2019 07:52
@kateinoigakukun
Copy link
Member Author

I updated to use WASI as target OS

@karwa
Copy link
Contributor

karwa commented Dec 3, 2019

The original patch is now over a year old, then it finally became unarguably ready to merge, so of course someone had to immediately go and refactor that part of code so it now needs rewriting 😅

One day we will finally catch up to the likes of C, Forth and Lua, and support WASM.

@kateinoigakukun
Copy link
Member Author

Hi, is there anything that prevents this PR from being merged?

@karwa
Copy link
Contributor

karwa commented Dec 12, 2019

@kateinoigakukun i believe @compnerd redid this after his changes and merged that version.

E.g. #28584

It would be great to rebase swiftwasm (there was another wasm-related patch, also from Saleem, after the one referenced above) based on master, and I think we can remove some hacks now that LLVM knows about WASI and that’s the „OS“ we support for WASM. I think @MaxDesiatov has write access to that repo.

I think we should really push ahead with upstreaming as many WASM patches as we can. This is a port that should be fairly easy to support via CI (basically all supported platforms can run WASM, even if it requires tools like wasmtime), and could be extremely useful for bootstrapping the Swift compiler if the driver project is ultimately successful at writing the compiler itself in Swift.

@kateinoigakukun kateinoigakukun deleted the katei/swasm-minimal-triple-support branch January 28, 2020 12:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants