[all-commits] [llvm/llvm-project] 9eb3e5: [ODS] Make the getType() method on a OneResult ins...

[Chris Lattner via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 9eb3e564d3b1c772a64eef6ecaa3b1705d065218
      https://github.com/llvm/llvm-project/commit/9eb3e564d3b1c772a64eef6ecaa3b1705d065218
  Author: Chris Lattner <clattner at nondot.org>
  Date:   2020-12-26 (Sat, 26 Dec 2020)

  Changed paths:
    M mlir/docs/Tutorials/Toy/Ch-2.md
    M mlir/examples/standalone/include/Standalone/StandaloneOps.h
    M mlir/include/mlir/Dialect/AVX512/AVX512Dialect.h
    M mlir/include/mlir/Dialect/ArmNeon/ArmNeonDialect.h
    M mlir/include/mlir/IR/OpBase.td
    M mlir/include/mlir/IR/OpDefinition.h
    M mlir/include/mlir/TableGen/Type.h
    M mlir/lib/Conversion/VectorToLLVM/ConvertVectorToLLVM.cpp
    M mlir/lib/Dialect/Vector/VectorOps.cpp
    M mlir/lib/Dialect/Vector/VectorTransforms.cpp
    M mlir/lib/TableGen/Type.cpp
    M mlir/tools/mlir-tblgen/OpDefinitionsGen.cpp

  Log Message:
  -----------
  [ODS] Make the getType() method on a OneResult instruction return a specific type.

Implement Bug 46698, making ODS synthesize a getType() method that returns a
specific C++ class for OneResult methods where we know that class.  This eliminates
a common source of casts in things like:

   myOp.getType().cast<FIRRTLType>().getPassive()

because we know that myOp always returns a FIRRTLType.  This also encourages
op authors to type their results more tightly (which is also good for
verification).

I chose to implement this by splitting the OneResult trait into itself plus a
OneTypedResult trait, given that many things are using `hasTrait<OneResult>`
to conditionalize various logic.

While this changes makes many many ops get more specific getType() results, it
is generally drop-in compatible with the previous behavior because 'x.cast<T>()'
is allowed when x is already known to be a T.  The one exception to this is that
we need declarations of the types used by ops, which is why a couple headers
needed additional #includes.

I updated a few things in tree to remove the now-redundant `.cast<>`'s, but there
are probably many more than can be removed.

Differential Revision: https://reviews.llvm.org/D93790