[PATCH] D26878: [GlobalISel] Add tentative Selector-emitted tablegen backend.

[Daniel Sanders via Phabricator via llvm-commits]

dsanders added inline comments.


================
Comment at: utils/TableGen/GlobalISelEmitter.cpp:99
+
+struct MatchAction {
+  virtual ~MatchAction() {}
----------------
ab wrote:
> dsanders wrote:
> > ab wrote:
> > > dsanders wrote:
> > > > This is a nitpick but I think we should keep Matchers and Actions in separate class hierarchies for type checking purposes. They don't share much implementation and it doesn't make sense to put MatchOpcode in Matcher::Actions or MutateOpcode in Matcher::Matchers
> > > Fair enough; split it into 'Matcher' and 'MatchAction', and renamed 'Matcher' to 'MatcherEmitter'.  Better names welcome ;)
> > For 'Matcher', could you elaborate that it's matching properties of an operand (OperandPropertyMatcher?). That way we won't have to rename it when we add additional levels of matching. For example, I've added an InstructionMatcher in my current WIP and I suspect I'll find an OperandMatcher useful now that we can have multiple matchers on a single operand.
> What about opcode matching though?  Are you thinking of a hierarchy of specialized Matchers ?  I can see it being useful, but I wouldn't worry about renaming everything once we get there ;)
Yes, I'm planning to have a hierarchy of matchers where MatchOpcode will be an instruction matcher and will contain the others (with an extra layer in between).

I'm thinking of having the following kinds of matchers:
* Instruction: An instruction matcher to match opcodes will be the main one but this is also where I'm thinking of handling the GlobalISel equivalent of ComplexPattern.
* Instruction Property: Fastmath, nuw/nsw, volatile, etc. I've separated this from instruction matchers to prevent combinatorial explosion in the instruction matchers.
* Operand: Matching a single operand by index will be the main one but I'm thinking it will also includes sequences to support variadic instructions.
* Operand Property: Types, register banks, constants, etc. but will also contain sub-instruction matchers such as:
  * Operand must be def'd by the same instruction as another (for tied-registers, special-case simplifications, etc.)
  * Operand must be def'd by an instruction matching a given instruction matcher and the two must be safely foldable (for multi-instruction patterns)


Repository:
  rL LLVM

https://reviews.llvm.org/D26878