[PATCH] D22373: [GlobalISel] Introduce a simple instruction selector.

Ahmed Bougacha via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 21 10:08:26 PDT 2016


ab added inline comments.

================
Comment at: include/llvm/CodeGen/GlobalISel/InstructionSelector.h:34-37
@@ +33,6 @@
+  /// \returns whether selection succeeded.
+  /// \pre  I.getParent() && I.getParent()->getParent()
+  /// \post if returns true: !isPreISelGenericOpcode(I.getOpcode())
+  virtual bool select(MachineInstr &I) const = 0;
+
+protected:
----------------
The XRay perspective is an interesting one.  Have you considered treating this as a legalization problem?  So, you insert your generic instructions at IR->MI translation time; the target declares how it wants to handle them.  If they're not legal, do your common, target-independent, lowering.  Would that make sense?


In general, I'd rather not have selection be "tentative", with fallbacks and whatnot.  I think one shared goal is to be able to definitively tell whether a given instruction will be selectable or not, without actually trying to select it. The hope is to then be able to statically figure out the constructs that "cannot select".

================
Comment at: include/llvm/Target/TargetSubtargetInfo.h:93-95
@@ +92,5 @@
+
+  virtual const InstructionSelector *getInstructionSelector() const {
+    return nullptr;
+  }
+
----------------
Sorry, I misread when I first answered.  Let me try again ;)

Yes, the InstructionSelector is intentionally specific to a subtarget.  Right now (especially for AArch64), there's not much to specialize, but I'm hoping that'll let us separate out feature-specific code  (so instead of a monster TLI, we could maybe have a hierarchy, say avx512>avx>sse, if that makes sense?)

================
Comment at: lib/CodeGen/GlobalISel/InstructionSelect.cpp:64-65
@@ +63,4 @@
+    }
+  }
+
+  // Check that we did select everything. Do this separately to make sure we
----------------
That's an interesting point;  first, do you agree that any of these invariants being violated is a bug? (be it in the legalizer, or in the IR translator, or ...)

The general idea is: an extended machine verifier - specialized for each phase, via MF properties - would enforce these invariant.  Anything coming into the selector has to be selectable.  It's the responsibility of the legalizer (and target-specific transforms, if applicable) to create well-formed instructions by then.


https://reviews.llvm.org/D22373





More information about the llvm-commits mailing list