[PATCH] D75098: Add COPY_BR, a terminator form of the COPY instr

Bill Wendling via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 25 13:11:55 PST 2020


void marked 7 inline comments as done.
void added inline comments.


================
Comment at: llvm/include/llvm/CodeGen/MachineInstr.h:1121
+    return getOpcode() == TargetOpcode::COPY ||
+        getOpcode() == TargetOpcode::COPY_BR;
   }
----------------
nickdesaulniers wrote:
> Does this save a few `getOpcode()` calls? The rest of this CL explicitly compares the opcode against `COPY_BR`? I just worry if this might mess up existing callsites of `isCopy` when `getOpcode() == TargetOpcode::COPY_BR;`.
It's more than just a few. `isCopy()` is used pretty extensively. I want the `COPY_BR` (or `COPY_TERM`) to be exactly like a normal `COPY`, with the only exception that it can come after a terminator.


================
Comment at: llvm/include/llvm/Support/TargetOpcodes.def:101
+/// COPY_BR - This instruction is the terminal version of COPY. The purpose is
+/// to allow copies from terminals to be properly represented (e.g. an
+/// INLINEASM_BR that defines a physical register) without having
----------------
arsenm wrote:
> arsenm wrote:
> > s/terminal/terminator
> COPY_TERM or COPY_TERMINATOR would be better since it isn't really a branch
How about `TCOPY`?


================
Comment at: llvm/include/llvm/Target/Target.td:1126
+  let isIndirectBranch = 1;
+}
 def BUNDLE : StandardPseudoInstruction {
----------------
nickdesaulniers wrote:
> `COPY` also sets `hasNoSchedulingInfo` to `0`. Should `COPY_BR` do that as well?
Possibly, though I had trouble finding where to place its scheduling info. It seems like `COPY` is special and TableGen adds it by default. I couldn't find the place to do that for `COPY_BR`, but I'll take another look.


================
Comment at: llvm/lib/CodeGen/ExpandPostRAPseudos.cpp:191
+  for (auto &MBB : MF) {
+    for (MachineBasicBlock::iterator mi = MBB.begin(), me = MBB.end();
          mi != me;) {
----------------
nickdesaulniers wrote:
> what? if we could use a range based for loop for the `MBB`'s, surely we can for `MI`.
The `++mi` below made me worried, and the fact that MI could be erased.


================
Comment at: llvm/lib/CodeGen/MachineSink.cpp:1397
+  if (InvalidateLiveness)
+    MF.getRegInfo().invalidateLiveness();
   return Changed;
----------------
nickdesaulniers wrote:
> Does it make sense to "sink" register info invalidation into `performSink()`? (pun intended) Since it's already checking the `MI`'s opcode? Or are the two call sites of `performSink()` problematic?  The implementation of `invalidateLiveness()` looks pretty cheap, IMO.
Possibly. If we're going to make `COPY_TERM` (or whatever name we settle on) not specific to `INLINEASM_BR`, then we'll probably need to modify this to accept any case where we sink copies after a terminator. We'll come back to this after other comments settle.


================
Comment at: llvm/lib/CodeGen/SelectionDAG/InstrEmitter.cpp:179
+    const MachineBasicBlock::iterator Term = MBB->getFirstTerminator();
+    if (Term != MBB->end() && Term->getOpcode() == TargetOpcode::INLINEASM_BR)
+      TgtOpc = TargetOpcode::COPY_BR;
----------------
arsenm wrote:
> I would expect this to not special case INLINEASM_BR. This should be any value defined by a terminator instruction
Does this include unconditional jump terminators?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75098





More information about the llvm-commits mailing list