i64x2 and f64x2 operations are not implemented in V8, so we normally
do not want to emit them. However, they are in the SIMD spec proposal,
so we still want to be able to test them in the toolchain. This patch
adds a flag to enable their emission.
Details
Diff Detail
- Repository
- rL LLVM
- Build Status
Buildable 21259 Build 21259: arc lint + arc unit
Event Timeline
lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp | ||
---|---|---|
45 | Could putting this declaration in WebAssemblyTargetMachine.h avoid all these extern declarations? |
lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp | ||
---|---|---|
45 | Not all, just some. |
lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp | ||
---|---|---|
49 | Are we planning to use this flag only for simd or also for other instructions? For example, exception handling is not currently implemented in the VM yet, but we are adding opcodes for it (under -mattr=+exception-handling flag). And in case if other stage 0~1 proposals come up, we may want to add them in the toolchain before they are implemented in the VM. Are we gonna use this flag for all these cases? If not, how about changing it to wasm-enable-unimplemented-simd? | |
test/CodeGen/WebAssembly/simd-arith.ll | ||
11 | How about leaving the meaning of SIMD128 as is and create another check mode for SIMD without the two opcodes? That way we can only delete that when we have the remaining two in the VM. And I think that also makes more sense if we are eventually gonna have them in the VM. |
lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp | ||
---|---|---|
45 | It also doesn't work that way because you end up with duplicate symbols. |
lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp | ||
---|---|---|
45 | I guess what he meant is putting the definition where it is now and putting that extern declaration in the header file, but anyway. |
lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp | ||
---|---|---|
49 | It may make sense to use the same flag for all cases where ops are implemented in the toolchain but not the VM. However, I'd be happy to change the name if this will only be used for SIMD. Would you want to have a single general flag for this use case, or are other existing mechanisms sufficient? |
lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp | ||
---|---|---|
49 | I don't think we need a separate flag that handles all unimplemented opcodes because we already have feature flags for each not-fully-implemented-and-ongoing feature. If we have enough cases like this, where a feature is controlled by a feature flag but we need a separation even within it, using this flag for all those cases might make sense. But before that, I guess making it clear that this applies only for SIMD is less confusing, because currently it sounds like it encompasses all unimplemented features. |
lib/Target/WebAssembly/WebAssemblyAsmPrinter.cpp | ||
---|---|---|
45 | Would WebAssembly.h work then? |
lib/Target/WebAssembly/WebAssembly.h | ||
---|---|---|
21 | Hmm, I'm not sure if we want to include this big header (and all other headers included by it) into all WebAssembly cpp files. Sorry. Maybe the original way would be better..? | |
lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp | ||
49 | Nit: can you also change the variable name to include simd? |
lib/Target/WebAssembly/WebAssemblyFastISel.cpp | ||
---|---|---|
688 | I don't think it's necessary to have checks at every single place where these types are used. It's enough e.g. to prevent them from reaching here with a check somewhere else, but still handle everything once the instructions get here. (Basically the same reason we have unconditional definitions and handling for simd instructions in some places, but have checks on the SIMD cpu feature in other places. |
Without all the checks I believe to be redundant this CL is much, much smaller. I'm concerned that it's possible the checks could save me a great deal of pain down the road, though.
Hmm, I'm not sure if we want to include this big header (and all other headers included by it) into all WebAssembly cpp files. Sorry. Maybe the original way would be better..?