[PATCH] D50823: [VPlan] Introduce VPCmpInst sub-class in the instruction-level representation

[Hideki Saito via Phabricator via llvm-commits]

hsaito added a comment.

In https://reviews.llvm.org/D50823#1202831, @rkruppe wrote:

> That said, this is currently the only subclass of its kind and it would be weird if it remained that way. In other words, I would expect that `VPInstruction` would gain more such subclasses (e.g., `VPBinaryOperator`, `VPSelectInst`, etc.) as the vectorizer starts to create and manipulate these instructions. Does this make sense to y'all?


Our general intention is to make VPInstructions as easy to use as Instructions to many LLVM developers, who aren't necessarily very familiar with vectorizer, and also reduce the duplicate development/maintenance effort. If that requires more subclassing, we'll consider doing that but very carefully, and only as needed basis. At this point, letting VPInstruction to have all the functionality of Instruction is not an objective. We are starting from implementing just enough to satisfy vectorizer needs and minimizing unnecessary divergence in doing so (i.e., what's implemented can be used in a very similar manner).

Sorry that I'm not directly answering your question. Hope this helps in evaluating between the two alternatives:  new opcode approach in https://reviews.llvm.org/D50480 and subclassing approach in this patch, however. I think subclassing here helps us avoid unnecessary divergence.


Repository:
  rL LLVM

https://reviews.llvm.org/D50823