[PATCH] D71484: [WebAssembly][InstrEmitter] Foundation for multivalue call lowering

Heejin Ahn via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 16 10:34:49 PST 2019


aheejin added a comment.

Mostly LGTM to me



================
Comment at: llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:837
+  bool HasPhysRegOuts = NumResults > NumDefs &&
+                        II.getImplicitDefs() != nullptr && !HasVRegVariadicDefs;
 #ifndef NDEBUG
----------------
Can't variadic-def call instructions also have implicit defs, such as `$argument`, `$sp32`, and `$sp64`?


================
Comment at: llvm/lib/Target/WebAssembly/MCTargetDesc/WebAssemblyMCTargetDesc.h:512
 /// instruction.
-inline unsigned getCalleeOpNo(unsigned Opc) {
-  switch (Opc) {
+inline const MachineOperand &getCalleeOp(const MachineInstr &MI) {
+  switch (MI.getOpcode()) {
----------------
I think the intention of D64643 was this file only contains methods that can work on `unsigned Opc` so that they can work equally on `MachineInstr`s and `MCInst`s. I now see that this function is not used for `MCInst`s now, but I think it'd better to make functions in this file consistently take `unsigned Opc`?


================
Comment at: llvm/lib/Target/WebAssembly/WebAssemblyISelDAGToDAG.cpp:219
+      if (Op->getOpcode() == WebAssemblyISD::Wrapper)
+        Op = Op->getOperand(0);
+      Ops.push_back(Op);
----------------
Why take out the wrapper?


================
Comment at: llvm/lib/Target/WebAssembly/WebAssemblyInstrCall.td:63
+defm CALL :
+  I<(outs), (ins function32_op:$callee, variable_ops),
+    (outs), (ins function32_op:$callee), [],
----------------
Just to clarify, even if `variable_ops` is within `(ins)`, if `variadicOpsAreDefs` is 1, are they considered as outputs? What happens if we put `variable_ops` in `(outs)`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71484





More information about the llvm-commits mailing list