Wed, Nov 13
- Remove Pass.h includes that are unnecessary now
Tue, Nov 12
Mon, Nov 4
Thu, Oct 31
Is this https://github.com/WebAssembly/simd/pull/27 ? Can you please include the spec (even if it's still an unmerged PR) in the CL description next time? LGTM.
Wed, Oct 30
LGTM. It's interesting that we can use MemIntrinsicNode for this purpose even if it's not an intrinsic...
(I guess we can also use MachineSDNode because we are effectively doing isel before we reach tablegen, but given that we've used it only in WebAssemblyISelDAGToDAG.cpp and we do most custom SIMD lowering in WebAssemblyISelLowering.cpp, this looks like a good trick.)
Oct 18 2019
Oct 15 2019
Oct 14 2019
Nice! Mostly LGTM.
Currently non-void blocks are only generated at the end of functions where the block return type needs to agree with the function return type, and that remains true for multivalue blocks. That invariant means that the actual signature does not need to be stored in the block signature MachineOperand because it can be inferred by WebAssemblyMCInstLower from the return type of the parent function.
I guess this is a tentative state before you implement the rest of the proposal in full, right? If other blocks are able to return multivalue, are we gonna change their operands to also take typeindex?
Oct 11 2019
Nice! Mostly LGTM.
Oct 9 2019
If swizzles are a lot more complicated that v128.const in execution, doesn't that mean swizzles will likely to take longer to execute in wasm? Why the opposite?
Swizzles lower directly to hardware instructions so they are fast for engines to execute. But doing the same operation without a swizzle instruction would require a long sequence of other wasm instructions and therefore be slow to execute. Because this difference is large for swizzles it is a good idea to prefer to use them when possible.
Oct 8 2019
We can make the decision based on whatever heuristic we want, but minimizing number of instructions seems like a good metric for now until we can run experiments to tune the selection algorithm.
Wouldn't minimizing the number of instruction be the same thing as minimizing the number of bytes, only more inaccurate?
LLVM produces a poison value if the dynamic swizzle indices are greater than the vector size, but the WebAssembly instruction sets the corresponding output lane to zero.
Where do we set those undef or poison lanes to zero?
- I remember before we had a somewhat complicated logic to calculate the number of bytes of total instructions of each case of the case we use v128.const and vs. when we use splats. Don't we need that anymore? Can we make the decision solely based the number of swizzles / consts / and splats?
Oct 7 2019
Thank you! Done in r374015.
Merging this, because this crashes builds.
Oct 6 2019
Rebase onto D68553
Oct 1 2019
Sep 30 2019
- Address comments
Sep 26 2019
Sep 23 2019
Mostly LGTM. By the way this contains diff of D67783 as well.
Sep 21 2019
LGTM as long as they are not used, but I'd like to check with @sunfish to be sure as well.
Sep 18 2019
+1 on erroring out on the backend side. And how about "wasm64 is not supported"? wasm64... is still a registered target in the frontend, so...
Sep 16 2019
What are the default values for those if we unset them?
Sep 15 2019
Sep 12 2019
Sep 11 2019
I think that's it.
Sep 10 2019
Can you give the link for the spec of these new instructions?
Sep 6 2019
- Error out when -fwasm-exceptions is specified with -mllvm -enable-emscripten-cxx-exceptions
What happens when users have exceptions in their code but don't pass Do they get the old SJLJ emulated exception handling?
Sep 5 2019
`-pthreads` enabling `-matomics` and `-mbulk-memory`make some sense because each of those low level flags might make sense on its own. But if `-fwasm-exceptions` only going to enable `-mexception-handling` then I'm not sure I see the point in adding it. Or is there something else it will enable?
If this is to be like -fdwarf-exceptions I assume the idea is that eventually it will default on when targeting wasm, and become one of those flags that most users never set. In that case it really just selects the default exception model, and thus it should be compatible with -fno-exceptions just as -fdwarf-exceptions is.\
But why not make -mexception-handling be the option that enabled everything? I mean -mexception-handling is a flag we have today.. if you add -fwasm-exceptions what does -mexception-handling meaning? Is it still useful?
@tlively @sbc100 What I wanted was to make -fwasm-exceptions as something like -pthreads, which serves as the only flag that needs to be turned on and turns on all other necessary flags, such as +matomics, +mbulk-memory, and --shared-memory. I think all those architectural flags starting with -m can be someday all turned on, when all our existing proposals become the new MVP, and I still want to give users an option to opt out of threads of exception handling at that point. And it also makes sense to have a LangOption of WasmExceptions given that there are LangOptions for all other exception models. I think this covers most of the questions above.