[PATCH] D55401: [WebAssembly] Fix assembler parsing of br_table.

Heejin Ahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 14 07:09:26 PST 2018


aheejin added inline comments.


================
Comment at: lib/Target/WebAssembly/InstPrinter/WebAssemblyInstPrinter.cpp:143
+      } else {
+        // A variable ops_operand, which currently can be immediates (used in
+        // br_table) which are basic block targets, or for call instructions
----------------
variable ops_operand -> variable_ops operand ?


================
Comment at: lib/Target/WebAssembly/InstPrinter/WebAssemblyInstPrinter.cpp:227
-    assert(OpNo < Desc.getNumOperands() &&
-           "Unexpected floating-point immediate as a non-fixed operand");
-    assert(Desc.TSFlags == 0 &&
----------------
aardappel wrote:
> aheejin wrote:
> > Why was this deleted too?
> Since we're basically not using variable_ops in the same way as before anymore (not annotated by TSFlags, not used in call in stack mode, and not used in br_table in the same way), keeping these checks didn't make much sense to me.
Oh what I asked is about
```
assert(OpNo < Desc.getNumOperands() &&
       "Unexpected floating-point immediate as a non-fixed operand");
```
Is this related to `TSFlags` or `variable_ops` too?


================
Comment at: lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCCodeEmitter.cpp:135
-      assert(i < Desc.getNumOperands() &&
-             "Unexpected floating-point immediate as a non-fixed operand");
-      assert(Desc.TSFlags == 0 &&
----------------
aardappel wrote:
> aheejin wrote:
> > Should this be deleted too?
> See above.
Oh what I asked is about
```
assert(OpNo < Desc.getNumOperands() &&
       "Unexpected floating-point immediate as a non-fixed operand");
```
Is this related to `TSFlags` or `variable_ops` too?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55401/new/

https://reviews.llvm.org/D55401





More information about the llvm-commits mailing list