[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