[drr] Enable specifying range in replacement.

[jpienaar]

Summary

This enables creating a replacement rule where range of positional replacements
need not be spelled out, or are not known (e.g., enable having a rewrite that
forward all operands to a call generically).

[Chia-hungDuan]

mlir/test/mlir-tblgen/rewriter-indexing.td

92

I'm thinking the form like "$...", which maps all the remaining. so in this case, we don't need to write down v1 ~ v3. Will this be clear?

In addition, for me, this form looks it will appear in something like,
// Binding the remaining args of SomeOp and select the range of arguments from $arg for AnotherOp.
def : Pat<(SomeOp $a0, $a1, $arg...), (AnotherOp $arg__3...)

[jpienaar]

mlir/test/mlir-tblgen/rewriter-indexing.td

92

Yes this one just changes it in the native call, not in the DAG specification.

With ops we have an explicit and fixed set of args, today one would match them by name or elide in matching with $_. We can already use native codecall expansion without changing dag matching (so these are independent but could work together). A potential problem with the dag format is it would be confusing with variadics.

[rriddle]

Can you update the description to specifically mention that this is for NativeCodeCalls? It wasn't clear on the first read.

Can you also add documentation for this feature to the .md docs?

mlir/lib/TableGen/Format.cpp

101

Can you just pass std::isdigit as is?

108

Can you add a comment here on what this is?

182–186

interleaveComma here? (using llvm::seq, or llvm::make_range on adaptors)

utils/bazel/llvm-project-overlay/mlir/BUILD.bazel

1501 ↗

(On Diff #354614)

This change looks unrelated.

[jpienaar]

use interleaveComma, update doc

[jpienaar]

Remove unrelated change

[jpienaar]

drop unrelated change really this time

[jpienaar]

mlir/lib/TableGen/Format.cpp

101

Depends on compiler, some yes others no it seems. Reverting to explicit lambda.

[rriddle]

mlir/lib/TableGen/Format.cpp

101

(You should be able to use llvm::isDigit then)

mlir/docs/DeclarativeRewrites.md

 # Table-driven Declarative Rewrite Rule (DRR)
 
 In addition to subclassing the `mlir::RewritePattern` C++ class, MLIR also
 supports defining rewrite rules in a declarative manner. Similar to
 [Op Definition Specification](OpDefinitions.md) (ODS), this is achieved via
 [TableGen][TableGen], which is a language to maintain records of domain-specific
 information. The rewrite rules are specified concisely in a TableGen record,
 which will be expanded into an equivalent `mlir::RewritePattern` subclass at
 compiler build time.
 
 This manual explains in detail all of the available mechanisms for defining
 rewrite rules in such a declarative manner. It aims to be a specification
 instead of a tutorial. Please refer to
-[Quickstart tutorial to adding MLIR graph
-rewrite](Tutorials/QuickstartRewrites.md) for the latter.
+[Quickstart tutorial to adding MLIR graph rewrite](Tutorials/QuickstartRewrites.md)
+for the latter.
 
 Given that declarative rewrite rules depend on op definition specification, this
 manual assumes knowledge of the [ODS](OpDefinitions.md) doc.
 
 ## Benefits
 
 Compared to the hand-written C++ classes, this declarative approach has several
 benefits, including but not limited to:

 Per the current implementation, DRR does not have good support for the following
 features:
 
 *   Matching and generating ops with regions.
 *   Matching and generating ops with block arguments.
 *   Matching multi-result ops in nested patterns.
 *   Matching and generating variadic operand/result ops in nested patterns.
 *   Packing and unpacking variadic operands/results during generation.
-*   [`NativeCodeCall`](#nativecodecall-transforming-the-generated-op)
-    returning more than one results.
+*   [`NativeCodeCall`](#nativecodecall-transforming-the-generated-op) returning
+    more than one results.
 
 ## Rule Definition
 
 The core construct for defining a rewrite rule is defined in
 [`OpBase.td`][OpBase] as
 
 ```tablegen
 class Pattern<

 
 Each pattern is specified as a TableGen `dag` object with the syntax of
 `(operator arg0, arg1, ...)`.
 
 `operator` is typically an MLIR op, but it can also be other
 [directives](#rewrite-directives). `argN` is for matching (if used in source
 pattern) or generating (if used in result pattern) the `N`-th argument for
 `operator`. If the `operator` is some MLIR operation, it means the `N`-th
-argument as specified in the `arguments` list of the op's definition.
-Therefore, we say op argument specification in pattern is **position-based**:
-the position where they appear matters.
+argument as specified in the `arguments` list of the op's definition. Therefore,
+we say op argument specification in pattern is **position-based**: the position
+where they appear matters.
 
 `argN` can be a `dag` object itself, thus we can have nested `dag` tree to model
 the def-use relationship between ops.
 
 ### Source pattern
 
 The source pattern is for matching a DAG of operations. Arguments in the `dag`
 object are intended to **capture** the op arguments. They can also be used to

 method for constructing the `COp`.
 
 In general, arguments in the result pattern will be passed directly to the
 `build()` method to leverage the auto-generated `build()` method, list them in
 the pattern by following the exact same order as the ODS `arguments` definition.
 Otherwise, a custom `build()` method that matches the argument list is required.
 
 Right now all ODS-generated `build()` methods require specifying the result
-type(s), unless the op has known traits like `SameOperandsAndResultType` that
-we can use to auto-generate a `build()` method with result type deduction.
-When generating an op to replace the result of the matched root op, we can use
-the matched root op's result type when calling the ODS-generated builder.
-Otherwise (e.g., generating an [auxiliary op](#supporting-auxiliary-ops) or
-generating an op with a nested result pattern), DRR will not be able to deduce
-the result type(s). The pattern author will need to define a custom builder
-that has result type deduction ability via `OpBuilder` in ODS. For example,
-in the following pattern
+type(s), unless the op has known traits like `SameOperandsAndResultType` that we
+can use to auto-generate a `build()` method with result type deduction. When
+generating an op to replace the result of the matched root op, we can use the
+matched root op's result type when calling the ODS-generated builder. Otherwise
+(e.g., generating an [auxiliary op](#supporting-auxiliary-ops) or generating an
+op with a nested result pattern), DRR will not be able to deduce the result
+type(s). The pattern author will need to define a custom builder that has result
+type deduction ability via `OpBuilder` in ODS. For example, in the following
+pattern
 
 ```tablegen
 def : Pat<(AOp $input, $attr), (COp (AOp $input, $attr) $attr)>;
 ```
 
 `AOp` is generated via a nested result pattern; DRR won't be able to deduce the
 result type for it. A custom builder for `AOp` should be defined and it should
 deduce the result type by itself. The builder should have the separate parameter

 
 In the above, we generate a `BOp`, and then use its result to generate the `COp`
 to replace the matched `AOp`.
 
 #### Binding op results
 
 In the result pattern, we can bind to the result(s) of a newly built op by
 attaching symbols to the op. (But we **cannot** bind to op arguments given that
-they are referencing previously bound symbols.) This is useful for reusing
-newly created results where suitable. For example,
+they are referencing previously bound symbols.) This is useful for reusing newly
+created results where suitable. For example,
 
 ```tablegen
 def DOp : Op<"d_op"> {
     let arguments = (ins
       AnyType:$d_input1,
       AnyType:$d_input2,
     );
 

 def : Pat<(TwoAttrOp $attr1, $attr2),
           (OneAttrOp (createArrayAttr $attr1, $attr2))>;
 ```
 
 And make sure the generated C++ code from the above pattern has access to the
 definition of the C++ helper function.
 
 In the above example, we are using a string to specialize the `NativeCodeCall`
-template. The string can be an arbitrary C++ expression that evaluates into
-some C++ object expected at the `NativeCodeCall` site (here it would be
-expecting an array attribute). Typically the string should be a function call.
+template. The string can be an arbitrary C++ expression that evaluates into some
+C++ object expected at the `NativeCodeCall` site (here it would be expecting an
+array attribute). Typically the string should be a function call.
 
 Note that currently `NativeCodeCall` must return no more than one value or
 attribute. This might change in the future.
 
 ##### `NativeCodeCall` placeholders
 
-In `NativeCodeCall`, we can use placeholders like `$_builder`, `$N`. The former
-is called _special placeholder_, while the latter is called _positional
-placeholder_.
+In `NativeCodeCall`, we can use placeholders like `$_builder`, `$N` and `$N...`.
+The former is called _special placeholder_, while the latter is called
+_positional placeholder_ and _positional range placeholder_.
 
 `NativeCodeCall` right now only supports three special placeholders:
 `$_builder`, `$_loc`, and `$_self`:
 
 *   `$_builder` will be replaced by the current `mlir::PatternRewriter`.
 *   `$_loc` will be replaced by the fused location or custom location (as
     determined by location directive).
 *   `$_self` will be replaced by the defining operation in a source pattern.

 could be `Attribute&` or `Attribute*`. Names with attribute constraints will be
 captured as Attributes while everything else will be treated as Value.
 
 Positional placeholders will be substituted by the `dag` object parameters at
 the `NativeCodeCall` use site. For example, if we define `SomeCall :
 NativeCodeCall<"someFn($1, $2, $0)">` and use it like `(SomeCall $in0, $in1,
 $in2)`, then this will be translated into C++ call `someFn($in1, $in2, $in0)`.
 
+Positional range placeholders will be substituted by multiple `dag` object
+parameters at the `NativeCodeCall` use site. For example, if we define
+`SomeCall : NativeCodeCall<"someFn($1...)">` and use it like `(SomeCall $in0,
+$in1, $in2)`, then this will be translated into C++ call `someFn($in1, $in2)`.
+
 ##### Customizing entire op building
 
 `NativeCodeCall` is not only limited to transforming arguments for building an
 op; it can be also used to specify how to build an op entirely. An example:
 
 If we have a C++ function for building an op:
 
 ```c++

 In the above we use the first result pattern to generate the first four ops, and
 use the last pattern to generate the last op, which is used to replace the
 matched op.
 
 ### Supporting multi-result ops
 
 Multi-result ops bring extra complexity to declarative rewrite rules. We use
 TableGen `dag` objects to represent ops in patterns; there is no native way to
-indicate that an op generates multiple results. The approach adopted is based
-on **naming convention**: a `__N` suffix is added to a symbol to indicate the
+indicate that an op generates multiple results. The approach adopted is based on
+**naming convention**: a `__N` suffix is added to a symbol to indicate the
 `N`-th result.
 
 #### `__N` suffix
 
 The `__N` suffix is specifying the `N`-th result as a whole (which can be
 [variadic](#supporting-variadic-ops)). For example, we can bind a symbol to some
 multi-result op and reference a specific result later:
 

 the `TwoResultOp`'s two results, respectively.
 
 #### Replacing multi-result ops
 
 The above example also shows how to replace a matched multi-result op.
 
 To replace an `N`-result op, the result patterns must generate at least `N`
 declared values (see [Declared vs. actual value](#declared-vs-actual-value) for
-definition). If there are more than `N` declared values generated, only the
-last `N` declared values will be used to replace the matched op. Note that
-because of the existence of multi-result op, one result pattern **may** generate
-multiple declared values. So it means we do not necessarily need `N` result
-patterns to replace an `N`-result op. For example, to replace an op with three
-results, you can have
+definition). If there are more than `N` declared values generated, only the last
+`N` declared values will be used to replace the matched op. Note that because of
+the existence of multi-result op, one result pattern **may** generate multiple
+declared values. So it means we do not necessarily need `N` result patterns to
+replace an `N`-result op. For example, to replace an op with three results, you
+can have
 
 ```tablegen
 // ThreeResultOp/TwoResultOp/OneResultOp generates three/two/one result(s),
 // respectively.
 
 // Replace each result with a result generated from an individual op.
 def : Pattern<(ThreeResultOp ...),
               [(OneResultOp ...), (OneResultOp ...), (OneResultOp ...)]>;

 regarding an op's values.
 
 *   _Value_: either an operand or a result
 *   _Declared operand/result/value_: an operand/result/value statically declared
     in ODS of the op
 *   _Actual operand/result/value_: an operand/result/value of an op instance at
     runtime
 
-The above terms are needed because ops can have multiple results, and some of the
-results can also be variadic. For example,
+The above terms are needed because ops can have multiple results, and some of
+the results can also be variadic. For example,
 
 ```tablegen
 def MultiVariadicOp : Op<"multi_variadic_op"> {
     let arguments = (ins
       AnyTensor:$input1,
       Variadic<AnyTensor>:$input2,
       AnyTensor:$input3
     );
 
     let results = (outs
       AnyTensor:$output1,
       Variadic<AnyTensor>:$output2,
       AnyTensor:$output3
     );
 }
 ```
 
 We say the above op has 3 declared operands and 3 declared results. But at
 runtime, an instance can have 3 values corresponding to `$input2` and 2 values
-correspond to `$output2`; we say it has 5 actual operands and 4 actual
-results. A variadic operand/result is a considered as a declared value that can
+correspond to `$output2`; we say it has 5 actual operands and 4 actual results.
+A variadic operand/result is a considered as a declared value that can
 correspond to multiple actual values.
 
 [TODO]
 
 ### Supplying additional constraints
 
 Constraints can be placed on op arguments when matching. But sometimes we need
 to also place constraints on the matched op's results or sometimes need to limit
*   Use normal `TypeConstraint`s on previous bound symbols (the first result of
     `TwoResultOp` must be a float tensor);
 *   Define new `Constraint` for previous bound symbols (the second result of
     `TwoResultOp` must has no use);
 *   Apply constraints on multiple bound symbols (`$input` and `TwoResultOp`'s
     first result must have the same element type).
 
 ### Adjusting benefits
 
-The benefit of a `Pattern` is an integer value indicating the benefit of matching
-the pattern. It determines the priorities of patterns inside the pattern rewrite
-driver. A pattern with a higher benefit is applied before one with a lower
-benefit.
+The benefit of a `Pattern` is an integer value indicating the benefit of
+matching the pattern. It determines the priorities of patterns inside the
+pattern rewrite driver. A pattern with a higher benefit is applied before one
+with a lower benefit.
 
 In DRR, a rule is set to have a benefit of the number of ops in the source
 pattern. This is based on the heuristics and assumptions that:
 
 *   Larger matches are more beneficial than smaller ones.
 *   If a smaller one is applied first the larger one may not apply anymore.
 
-
 The fourth parameter to `Pattern` (and `Pat`) allows to manually tweak a
 pattern's benefit. Just supply `(addBenefit N)` to add `N` to the benefit value.
 
 ## Rewrite directives
 
 ### `location`
 
 By default the C++ pattern expanded from a DRR pattern uses the fused location

 
 `location` must be used as the last argument to an op creation. For example,
 
 ```tablegen
 def : Pat<(LocSrc1Op:$src1 (LocSrc2Op:$src2 ...),
           (LocDst1Op (LocDst2Op ..., (location $src2)), (location "outer"))>;
 ```
 
-In the above pattern, the generated `LocDst2Op` will use the matched location
-of `LocSrc2Op` while the root `LocDst1Op` node will used the named location
+In the above pattern, the generated `LocDst2Op` will use the matched location of
+`LocSrc2Op` while the root `LocDst1Op` node will used the named location
 `outer`.
 
 ### `replaceWithValue`
 
 The `replaceWithValue` directive is used to eliminate a matched op by replacing
 all of it uses with a captured value. It is of the following syntax:
 
 ```tablegen

 
 The above pattern removes the `Foo` and replaces all uses of `Foo` with
 `$input`.
 
 ## Debugging Tips
 
 ### Run `mlir-tblgen` to see the generated content
 
-TableGen syntax sometimes can be obscure; reading the generated content can be
-a very helpful way to understand and debug issues. To build `mlir-tblgen`, run
+TableGen syntax sometimes can be obscure; reading the generated content can be a
+very helpful way to understand and debug issues. To build `mlir-tblgen`, run
 `cmake --build . --target mlir-tblgen` in your build directory and find the
 `mlir-tblgen` binary in the `bin/` subdirectory. All the supported generators
 can be found via `mlir-tblgen --help`.
 
 To see the generated code, invoke `mlir-tblgen` with a specific generator by
 providing include paths via `-I`. For example,
 
 ```sh

mlir/include/mlir/TableGen/Format.h

private:
   };
 
   llvm::SmallDenseMap<PHKind, std::string, 4, PHKindInfo> builtinSubstMap;
   llvm::StringMap<std::string> customSubstMap;
 };
 
 /// Struct representing a replacement segment for the formatted string. It can
 /// be a segment of the formatting template (for `Literal`) or a replacement
-/// parameter (for `PositionalPH` and `SpecialPH`).
+/// parameter (for `PositionalPH`, `PositionalRangePH` and `SpecialPH`).
 struct FmtReplacement {
-  enum class Type { Empty, Literal, PositionalPH, SpecialPH };
+  enum class Type {
+    Empty,
+    Literal,
+    PositionalPH,
+    PositionalRangePH,
+    SpecialPH
+  };
 
   FmtReplacement() = default;
   explicit FmtReplacement(StringRef literal)
       : type(Type::Literal), spec(literal) {}
   FmtReplacement(StringRef spec, size_t index)
       : type(Type::PositionalPH), spec(spec), index(index) {}
+  FmtReplacement(StringRef spec, size_t index, size_t end)
+      : type(Type::PositionalRangePH), spec(spec), index(index), end(end) {}
   FmtReplacement(StringRef spec, FmtContext::PHKind placeholder)
       : type(Type::SpecialPH), spec(spec), placeholder(placeholder) {}
 
   Type type = Type::Empty;
   StringRef spec;
   size_t index = 0;
+  size_t end = kUnset;
   FmtContext::PHKind placeholder = FmtContext::PHKind::None;
+
+  static constexpr size_t kUnset = -1;
 };
 
 class FmtObjectBase {
 private:
   static std::pair<FmtReplacement, StringRef> splitFmtSegment(StringRef fmt);
   static std::vector<FmtReplacement> parseFormatString(StringRef fmt);
 
 protected:
   // The parameters are stored in a std::tuple, which does not provide runtime
   // indexing capabilities.  In order to enable runtime indexing, we use this
   // structure to put the parameters into a std::vector.  Since the parameters
   // are not all the same type, we use some type-erasure by wrapping the
   // parameters in a template class that derives from a non-template superclass.
   // Essentially, we are converting a std::tuple<Derived<Ts...>> to a
   // std::vector<Base*>.
   struct CreateAdapters {
     template <typename... Ts>
-    std::vector<llvm::detail::format_adapter *> operator()(Ts &... items) {
+    std::vector<llvm::detail::format_adapter *> operator()(Ts &...items) {
       return std::vector<llvm::detail::format_adapter *>{&items...};
     }
   };
 
   StringRef fmt;
   const FmtContext *context;
   std::vector<llvm::detail::format_adapter *> adapters;
   std::vector<FmtReplacement> replacements;
private:
   SmallVector<StrFormatAdapter, 16> parameters;
 };
 
 /// Formats text by substituting placeholders in format string with replacement
 /// parameters.
 ///
 /// There are two categories of placeholders accepted, both led by a '$' sign:
 ///
-/// 1. Positional placeholder: $[0-9]+
+/// 1.a Positional placeholder: $[0-9]+
+/// 1.b Positional range placeholder: $[0-9]+...
 /// 2. Special placeholder:    $[a-zA-Z_][a-zA-Z0-9_]*
 ///
 /// Replacement parameters for positional placeholders are supplied as the
 /// `vals` parameter pack with 1:1 mapping. That is, $0 will be replaced by the
 /// first parameter in `vals`, $1 by the second one, and so on. Note that you
 /// can use the positional placeholders in any order and repeat any times, for
 /// example, "$2 $1 $1 $0" is accepted.
 ///
+/// Replace parameters for positional range placeholders are supplied as if
+/// positional placeholders were specified with commas separating them.
+///
 /// Replacement parameters for special placeholders are supplied using the `ctx`
 /// format context.
 ///
 /// The `fmt` is recorded as a `StringRef` inside the returned `FmtObject`.
 /// The caller needs to make sure the underlying data is available when the
 /// `FmtObject` is used.
 ///
 /// `ctx` accepts a nullptr if there is no special placeholder is used.
 ///
 /// If no substitution is provided for a placeholder or any error happens during
 /// format string parsing or replacement, the placeholder will be outputted
 /// as-is with an additional marker '<no-subst-found>', to aid debugging.
 ///
 /// To print a '$' literally, escape it with '$$'.
 ///
 /// This utility function is inspired by LLVM formatv(), with modifications
 /// specially tailored for TableGen C++ generation usage:
 ///
 /// 1. This utility use '$' instead of '{' and '}' for denoting the placeholder
 ///    because '{' and '}' are frequently used in C++ code.
 /// 2. This utility does not support format layout because it is rarely needed
 ///    in C++ code generation.
 template <typename... Ts>
-inline auto tgfmt(StringRef fmt, const FmtContext *ctx, Ts &&... vals)
+inline auto tgfmt(StringRef fmt, const FmtContext *ctx, Ts &&...vals)
     -> FmtObject<decltype(std::make_tuple(
         llvm::detail::build_format_adapter(std::forward<Ts>(vals))...))> {
   using ParamTuple = decltype(std::make_tuple(
       llvm::detail::build_format_adapter(std::forward<Ts>(vals))...));
   return FmtObject<ParamTuple>(
       fmt, ctx,
       std::make_tuple(
           llvm::detail::build_format_adapter(std::forward<Ts>(vals))...));

mlir/lib/TableGen/Format.cpp

FmtObjectBase::splitFmtSegment(StringRef fmt) {
   // Allow escaping dollar with '$$'
   if (fmt[1] == '$') {
     return {FmtReplacement{fmt.substr(0, 1)}, fmt.substr(2)};
   }
 
   // First try to see if it's a positional placeholder, and then handle special
   // placeholders.
 
-  size_t end = fmt.find_if_not([](char c) { return std::isdigit(c); }, 1);
+  size_t end = fmt.find_if_not(std::isdigit, /*From=*/1);
   if (end != 1) {
     // We have a positional placeholder. Parse the index.
     size_t index = 0;
     if (fmt.substr(1, end - 1).consumeInteger(0, index)) {
       llvm_unreachable("invalid replacement sequence index");
     }
 
+    // Check if this is the part of a range specification.
+    if (fmt.substr(end, 3) == "...") {
+      // Currently only ranges without upper bound are supported.
+      return {
+          FmtReplacement{fmt.substr(0, end + 3), index, FmtReplacement::kUnset},
+          fmt.substr(end + 3)};
+    }
+
     if (end == StringRef::npos) {
       // All the remaining characters are part of the positional placeholder.
       return {FmtReplacement{fmt, index}, StringRef()};
     }
     return {FmtReplacement{fmt.substr(0, end), index}, fmt.substr(end)};
   }
 
   end = fmt.find_if_not([](char c) { return std::isalnum(c) || c == '_'; }, 1);
if (repl.type == FmtReplacement::Type::SpecialPH) {
         if (subst)
           s << *subst;
         else
           s << repl.spec << kMarkerForNoSubst;
       }
       continue;
     }
 
+    if (repl.type == FmtReplacement::Type::PositionalRangePH) {
+      if (repl.index >= adapters.size()) {
+        s << repl.spec << kMarkerForNoSubst;
+        continue;
+      }
+      auto range = llvm::makeArrayRef(adapters);
+      range = range.drop_front(repl.index);
+      if (repl.end != FmtReplacement::kUnset)
+        range = range.drop_back(adapters.size() - repl.end);
+      llvm::interleaveComma(range, s,
+                            [&](auto &x) { x->format(s, /*Options=*/""); });
+      continue;
+    }
+
     assert(repl.type == FmtReplacement::Type::PositionalPH);
 
     if (repl.index >= adapters.size()) {
       s << repl.spec << kMarkerForNoSubst;
       continue;
     }
     adapters[repl.index]->format(s, /*Options=*/"");
   }

mlir/test/mlir-tblgen/rewriter-indexing.td

NativeCodeCall<[{
     nativeCall($_builder, $_loc, $0, $1, $2, $3, $4, $5, $6, $7, $8, $9)
   }]>;
 
 // Check Pattern with large number of DAG arguments passed to NativeCodeCall
 // CHECK: struct test4 : public ::mlir::RewritePattern {
 // CHECK: nativeCall(rewriter, odsLoc, (*v1.begin()), (*v2.begin()), (*v3.begin()), (*v4.begin()), (*v5.begin()), (*v6.begin()), (*v7.begin()), (*v8.begin()), (*v9.begin()), (*v10.begin()))
 def test4 : Pat<(DOp $v1, $v2, $v3, $v4, $v5, $v6, $v7, $v8, $v9, $v10),
                 (NativeBuilder $v1, $v2, $v3, $v4, $v5, $v6, $v7, $v8, $v9, $v10)>;
+
+// CHECK: struct test5 : public ::mlir::RewritePattern {
+// CHECK: foo(rewriter, (*v4.begin()), (*v5.begin()), (*v6.begin()), (*v7.begin()), (*v8.begin()), (*v9.begin()), (*v10.begin()))
+def test5 : Pat<(DOp $v1, $v2, $v3, $v4, $v5, $v6, $v7, $v8, $v9, $v10),
+                (NativeCodeCall<[{ foo($_builder, $3...) }]> $v1, $v2, $v3, $v4, $v5, $v6, $v7, $v8, $v9, $v10)>;