In D68889#1706857, @aheejin wrote:

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?

Nice! Mostly LGTM.

In D68527#1701774, @tlively wrote:

In D68527#1700939, @aheejin wrote:

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.

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?

Thank you! Done in r374015.

Merging this, because this crashes builds.

Rebase onto D68553

• Address comments

Mostly LGTM. By the way this contains diff of D67783 as well.

LGTM as long as they are not used, but I'd like to check with @sunfish to be sure as well.

+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...

What are the default values for those if we unset them?

LGTM.

• Maybe we can lower these to these new instructions later? (I'm not very sure what the difference between versions with and without VECTOR, because the versions without VECTOR seem to be able to take vector arguments as well.)
• Will this simplify the complicated lowering of SIGN_EXTEND_INREG?

I think that's it.

Can you give the link for the spec of these new instructions?

• Error out when -fwasm-exceptions is specified with -mllvm -enable-emscripten-cxx-exceptions

In D67208#1661694, @tlively wrote:

What happens when users have exceptions in their code but don't pass Do they get the old SJLJ emulated exception handling?

In D67208#1660041, @sbc100 wrote:

`-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?

In D67208#1659972, @dschuff wrote:

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.\

In D67208#1659941, @sbc100 wrote:

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.

• Remove a blank line

LGTM % nits if tests pass.

• Renamed to lower-em-sjlj-alias.ll

Yeah I think that can be a more generalized solution too.

Should we handle these too?

• There seems to be a generic intrinsic for fused multiply-add: https://github.com/llvm/llvm-project/blob/d21a3e41a4cfd52e3c5c9341f0b5ce8a173198bf/llvm/include/llvm/Target/GenericOpcodes.td#L612-L619
• There are FMA related nodes in ISDOpcode.h, such as
  • https://github.com/llvm/llvm-project/blob/1ea909270c6d9ad612a46c2a15c13acc4f6d623a/llvm/include/llvm/CodeGen/ISDOpcodes.h#L332-L337
  • https://github.com/llvm/llvm-project/blob/1ea909270c6d9ad612a46c2a15c13acc4f6d623a/llvm/include/llvm/CodeGen/ISDOpcodes.h#L294

In D66983#1653226, @tlively wrote:

The code that does the undesirable optimization is around llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:18776.

Could you point to the spec of these instructions?