This patch adds initial WebAssembly support in clang. The WebAssembly target is currently experimental.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
include/clang/Basic/TargetCXXABI.h | ||
---|---|---|
166 | @rengolin: FYI. | |
lib/Basic/Targets.cpp | ||
6935 | That's already the default? | |
6937 | Already the default? | |
6938 | TLSSupported = false for now. | |
6941 | Not needed, since that's the default impl? | |
6956 | I'm not sure we need this. Does it just make porting easier? | |
6983 | final for these two. | |
6994 | final | |
7015 | final | |
lib/Driver/Tools.cpp | ||
1559 | New comment style without name -. | |
test/CodeGen/wasm-arguments.c | ||
92 | TODO for vararg test? | |
test/Driver/wasm32-unknown-unknown.cpp | ||
52 | Also test __wasm32__ (and 64 in the other file). | |
65 | Test __REGISTER_PREFIX__ if we do keep it. | |
test/Preprocessor/init.c | ||
8478 | ATOMIC_*_LOCK_FREE should always be 1 for "maybe". |
lib/Basic/Targets.cpp | ||
---|---|---|
6935 | I thought I'd leave it in while we discuss whether this is really what we want. | |
6937 | Right. | |
6938 | Since the MVP doesn't have threads at all, all variables are TLS :-). And after the MVP, we'll add threads with TLS. Is there a downside to leaving this on for now? It'll make the thread prototyping work easier. | |
6941 | We're going to put code in there before long anyway, so there's no harm in getting it ready. | |
6956 | I don't know if we specifically need it; I just included it because lots of other popular targets have it. | |
6983 | Right. | |
6994 | This class is subclassed. | |
7015 | This one is too. | |
lib/Driver/Tools.cpp | ||
1559 | Right. | |
test/CodeGen/wasm-arguments.c | ||
92 | There's a TODO for "implement va_list properly" elsewhere, so we can add tests when we actually implement it. | |
test/Driver/wasm32-unknown-unknown.cpp | ||
52 | test/Preprocessor/init.c covers this. | |
65 | test/Preprocessor/init.c covers this. | |
test/Preprocessor/init.c | ||
8478 | Clang is setting these automatically based on the value of MaxAtomicInlineWidth. Are you saying 32 is the wrong value for wasm32? This is perhaps a discussion to be had on the spec side. The value for wasm64 is also an interesting topic for the spec side. |
- use more default values in WebAssemblyTargetInfo etc.
- add a comment about using ARM-C++-ABI-style guard variables (for now)
- fix diff to include context for Phabricator
lib/Basic/Targets.cpp | ||
---|---|---|
6953 | I've now removed this (for now; we can discuss what to do in a later patch). |
lib/Basic/Targets.cpp | ||
---|---|---|
6956 | True, leaving it as is sgtm. | |
7012 | Weird, the comment moved around. I put it on WebAssembly32TargetInfo which doesn't seem subclassed? Same for 64. Or is that going to be on the LLVM side? final on getTargetDefines instead? | |
test/Preprocessor/init.c | ||
8478 | Yes, we don't know yet whether we guarantee atomicity so returning "maybe" is the conservative thing (which we can change in the future). We can discuss what we guarantee on the spec side, but for now the conservative thing is better IMO (and changing it isn't a problem, whereas changing "always" is a problem). FWIW N4509 is relevant. |
- set MaxAtomicInlineWidth to 0 for now (sets *_ATOMIC_*_LOCK_FREE to 1)
- enable LargeArrayAlign
- enable __int128
- various cleanups
lib/Basic/Targets.cpp | ||
---|---|---|
7012 | WebAssembly32TargetInfo is subclassed in LLVM code, and getTargetDefines is overridden. | |
test/Preprocessor/init.c | ||
8478 | Ok, I've set MaxAtomicInlineWidth to 0 for now so that we don't block the rest of the patch on this issue. N4509 is just about exposing the same information via a different interface. |
The patch evolved enough to prompt posting one more new version; major changes:
- make constructors and destructors return this
- enable -fuse-init-array
- enable -fno-common
- disable -mdisable-fp-elim
- put static init code in ".text.__startup"
- define a "+simd128" feature, -msimd128 option, wasm_simd128 macro
- ignore empty struct arguments and return values
- more tests
Minor updates to keep the patch building and working as code changes around it. Also enabled -mthread-model.
Some inline comments.
Thanks!
-eric
include/clang/Basic/TargetCXXABI.h | ||
---|---|---|
166 | Can you elaborate on the comment here as to what the alignment here means or something? It looks incomplete otherwise. | |
lib/Basic/Targets.cpp | ||
6992–6998 | Might make sense to copy the x86 bits here? | |
7699–7724 | Seems overly complicated? Maybe just a positive test? | |
lib/CodeGen/CodeGenModule.cpp | ||
809 | Update the comment? | |
lib/Driver/ToolChains.cpp | ||
3835–3855 | No generic defaults here? Might also make sense to have these all inline if they're just return true/return false. | |
lib/Driver/Tools.cpp | ||
1567–1572 | I really dislike the idea of an ifdef here for this behavior. Can you explain some more? :) |
Thanks for the review!
include/clang/Basic/TargetCXXABI.h | ||
---|---|---|
166 | Ok, I'll add a longer comment. | |
lib/Basic/Targets.cpp | ||
6992–6998 | The x86 bits don't handle "-" attributes, so it's not directly applicable. | |
7699–7724 | Good idea. I'll do that. | |
lib/CodeGen/CodeGenModule.cpp | ||
809 | Ok, I'll write a bit more here. | |
lib/Driver/ToolChains.cpp | ||
3835–3855 | All these functions are returning non-default values or are overriding pure virtual functions. And they're outline because they're virtual overrides, so there's little optimization advantage to defining them in the header. And it's what most of the other toolchain definitions do most of the time. | |
lib/Driver/Tools.cpp | ||
1567–1572 | As we discussed on IRC, I'll remove this code for now. |
Updated to address review comments:
- added comments
- simplified Triple validation code
- removed -mcpu="native" code
A couple things inline that need changing, but feel free to commit after without a repost.
-eric
lib/Basic/Targets.cpp | ||
---|---|---|
7000–7001 | The backend should handle any weirdness here with missing features especially as this will report an error based on -cc1 compilation and not the main command line. I.e. it's not necessary, that said if you feel wedded to it there's no problem either. | |
7701–7705 | Why not just a positive test? | |
7709–7715 | Ditto. (I said this just below, but it seems to have gotten munged in the newer version) |
lib/Basic/Targets.cpp | ||
---|---|---|
7000–7001 | I do feel more comfortable rejecting anything that I'm not specifically expecting in this area. | |
7709–7715 | I actually did see your comment and updated the code accordingly. It now does a positive test, Triple == llvm::Triple("wasm64-unknown-unknown"), which is simpler than what it did before. However, it's also doing additional tests, because the Triple class's operator== doesn't distinguish between an Unknown that was actually "unknown" or an unknown that was some other string. Until we figure out what "vendor", "OS", and "environment" variations of wasm make sense (if any), we want to avoid dealing with accidental alternate triples. |
lib/Basic/Targets.cpp | ||
---|---|---|
7709–7715 | I think this is a lot of overkill here, no other target cares about this so why should the wasm target? If it's that important maybe fix Triple? |
lib/Basic/Targets.cpp | ||
---|---|---|
7709–7715 | This Triple issue is not important enough to hold up the rest of the patch for, so I just removed it. Thanks for the review! |
@rengolin: FYI.