[spirv] Remove one level of indirection: processOp to processOpImpl

We already have two levels of controls in SPIRVBase.td: hasOpcode and
autogenSerialization. The former controls whether to add an entry to
the dispatch table, while the latter controls whether to autogenerate
the op's (de)serialization method specialization. This is enough for
our cases. Remove the indirection from processOp to processOpImpl
to simplify the picture.

PiperOrigin-RevId: 259308711

1 files changed, 1 insertions, 5 deletions

diff --git a/mlir/lib/Dialect/SPIRV/Serialization/Serializer.cpp b/mlir/lib/Dialect/SPIRV/Serialization/Serializer.cpp
index 18a2e10bcd4..d29e7177449 100644
--- a/mlir/lib/Dialect/SPIRV/Serialization/Serializer.cpp
+++ b/mlir/lib/Dialect/SPIRV/Serialization/Serializer.cpp
@@ -151,10 +151,6 @@ private:
   /// an instruction in the SPIR-V spec. This is auto generated if hasOpcode ==
   /// 1 and autogenSerialization == 1 in ODS.
   template <typename OpTy> LogicalResult processOp(OpTy op) {
-    return processOpImpl(op);
-  }
-
-  template <typename OpTy> LogicalResult processOpImpl(OpTy op) {
     return op.emitError("unsupported op serialization");
   }
 
@@ -490,7 +486,7 @@ Serializer::processOp<spirv::ExecutionModeOp>(spirv::ExecutionModeOp op) {
 }
 
 // Pull in auto-generated Serializer::dispatchToAutogenSerialization() and
-// various processOpImpl specializations.
+// various Serializer::processOp<...>() specializations.
 #define GET_SERIALIZATION_FNS
 #include "mlir/Dialect/SPIRV/SPIRVSerialization.inc"
 } // namespace