Add an __attribute__((unused)) to populateWithGenerated since it might
not be used where defined and is autogenerated.

NFC: Replace ValuePtr with Value and remove it now that Value is value-typed.

ValuePtr was a temporary typedef during the transition to a value-typed Value.

PiperOrigin-RevId: 286945714

Adjust License.txt file to use the LLVM license

PiperOrigin-RevId: 286906740

NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to Value being value-typed.

This is an initial step to refactoring the representation of OpResult as proposed in: https://gro

NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to Value being value-typed.

This is an initial step to refactoring the representation of OpResult as proposed in: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ

This change will make it much simpler to incrementally transition all of the existing code to use value-typed semantics.

PiperOrigin-RevId: 286844725

show more ...

Remove unused variable (fix warning) NFC

PiperOrigin-RevId: 285799680

minor spelling tweaks

Closes tensorflow/mlir#290

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/290 from kiszk:spelling_tweaks_201912 9d9afd16a723dd65754a04698b3976f150a6054a
Pip

minor spelling tweaks

Closes tensorflow/mlir#290

COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/290 from kiszk:spelling_tweaks_201912 9d9afd16a723dd65754a04698b3976f150a6054a
PiperOrigin-RevId: 284169681

show more ...

[ODS] Generate builders taking unwrapped value and defaults for attributes

Existing builders generated by ODS require attributes to be passed
in as mlir::Attribute or its subclasses. This is okay fo

[ODS] Generate builders taking unwrapped value and defaults for attributes

Existing builders generated by ODS require attributes to be passed
in as mlir::Attribute or its subclasses. This is okay foraggregate-
parameter builders, which is primarily to be used by programmatic
C++ code generation; it is inconvenient for separate-parameter
builders meant to be called in manually written C++ code because
it requires developers to wrap raw values into mlir::Attribute by
themselves.

This CL extends to generate additional builder methods that
take raw values for attributes and handles the wrapping in the
builder implementation. Additionally, if an attribute appears
late in the arguments list and has a default value, the default
value is supplied in the declaration if possible.

PiperOrigin-RevId: 283355919

show more ...

[DRR] Introduce `$_` to ignore op argument match

Right now op argument matching in DRR is position-based, meaning we need to
specify N arguments for an op with N ODS-declared argument. This can be a

[DRR] Introduce `$_` to ignore op argument match

Right now op argument matching in DRR is position-based, meaning we need to
specify N arguments for an op with N ODS-declared argument. This can be annoying
when we don't want to capture all the arguments. `$_` is to remedy the situation.

PiperOrigin-RevId: 283339992

show more ...

Add support for AttrSizedOperandSegments/AttrSizedResultSegments

Certain operations can have multiple variadic operands and their size
relationship is not always known statically. For such cases, we

Add support for AttrSizedOperandSegments/AttrSizedResultSegments

Certain operations can have multiple variadic operands and their size
relationship is not always known statically. For such cases, we need
a per-op-instance specification to divide the operands into logical
groups or segments. This can be modeled by attributes.

This CL introduces C++ trait AttrSizedOperandSegments for operands and
AttrSizedResultSegments for results. The C++ trait just guarantees
such size attribute has the correct type (1D vector) and values
(non-negative), etc. It serves as the basis for ODS sugaring that
with ODS argument declarations we can further verify the number of
elements match the number of ODS-declared operands and we can generate
handy getter methods.

PiperOrigin-RevId: 282467075

show more ...

Use aggregate-parameter builder for ops having autogen type-deduction builder

Thus far DRR always invokes the separate-parameter builder (i.e., requiring
a separate parameter for each result-type/op

Use aggregate-parameter builder for ops having autogen type-deduction builder

Thus far DRR always invokes the separate-parameter builder (i.e., requiring
a separate parameter for each result-type/operand/attribute) for creating
ops, no matter whether we can auto-generate a builder with type-deduction
ability or not.

This CL changes the path for ops that we can auto-generate type-deduction
builders, i.e., with SameOperandsAndResultType/FirstAttrDerivedResultType
traits. Now they are going through a aggregate-parameter builder (i.e.,
requiring one parameter for all result-types/operands/attributes).
attributes.)

It is expected this approach will be more friendly for future shape inference
function autogen and calling those autogen'd shape inference function without
excessive packing and repacking operand/attribute lists.
Also, it would enable better support for creating ops with optional attributes
because we are not required to provide an Attribute() as placeholder for
an optional attribute anymore.

PiperOrigin-RevId: 280654800

show more ...

[DRR] Allow interleaved operands and attributes

Previously DRR assumes attributes to appear after operands. This was the
previous requirements on ODS, but that has changed some time ago. Fix
DRR to

[DRR] Allow interleaved operands and attributes

Previously DRR assumes attributes to appear after operands. This was the
previous requirements on ODS, but that has changed some time ago. Fix
DRR to also support interleaved operands and attributes.

PiperOrigin-RevId: 275983485

show more ...

[DRR] Address GCC warning by wrapping for statement body with {}

Otherwise, we'll see the following warning when compiling with GCC 8:

warning: this ?for? clause does not guard... [-Wmisleading-ind

[DRR] Address GCC warning by wrapping for statement body with {}

Otherwise, we'll see the following warning when compiling with GCC 8:

warning: this ?for? clause does not guard... [-Wmisleading-indentation]
PiperOrigin-RevId: 275735925

show more ...

[DRR] Use eraseOp() to replace no-result ops

PiperOrigin-RevId: 275475229

Fix RewriterGen to support using NativeCodeCall as auxiliary pattern

NativeCodeCall is handled differently than normal op creation in RewriterGen
(because its flexibility). It will only be materiali

Fix RewriterGen to support using NativeCodeCall as auxiliary pattern

NativeCodeCall is handled differently than normal op creation in RewriterGen
(because its flexibility). It will only be materialized to output stream if
it is used. But when using it for auxiliary patterns, we still want the side
effect even if it is not replacing matched root op's results.

PiperOrigin-RevId: 275265467

show more ...

Add LLVM_DEBUG in RewritersGen.cpp and Pattern.cpp

It's usually hard to understand what went wrong if mlir-tblgen
crashes on some input. This CL adds a few useful LLVM_DEBUG
statements so that we ca

Add LLVM_DEBUG in RewritersGen.cpp and Pattern.cpp

It's usually hard to understand what went wrong if mlir-tblgen
crashes on some input. This CL adds a few useful LLVM_DEBUG
statements so that we can use mlir-tblegn -debug to figure
out the culprit for a crash.

PiperOrigin-RevId: 275253532

show more ...

Fix typos, NFC.

PiperOrigin-RevId: 272851237

Make result ops generated output deterministic

Sort the result ops reported in lexographical order.

PiperOrigin-RevId: 271426258

Support variadic ops in declarative rewrite rules

This CL extends declarative rewrite rules to support matching and
generating ops with variadic operands/results. For this, the
generated `matchAndRe

Support variadic ops in declarative rewrite rules

This CL extends declarative rewrite rules to support matching and
generating ops with variadic operands/results. For this, the
generated `matchAndRewrite()` method for each pattern now are
changed to

* Use "range" types for the local variables used to store captured
values (`operand_range` for operands, `ArrayRef<Value *>` for
values, *Op for results). This allows us to have a unified way
of handling both single values and value ranges.
* Create local variables for each operand for op creation. If the
operand is variadic, then a `SmallVector<Value*>` will be created
to collect all values for that operand; otherwise a `Value*` will
be created.
* Use a collective result type builder. All result types are
specified via a single parameter to the builder.

We can use one result pattern to replace multiple results of the
matched root op. When that happens, it will require specifying
types for multiple results. Add a new collective-type builder.

PiperOrigin-RevId: 264588559

show more ...

NFC: Don't assume that all operation traits are within the 'OpTrait::' namespace.

This places an unnecessary restriction that all traits are within this namespace.

PiperOrigin-RevId: 264212000

NFC: Refactoring PatternSymbolResolver into SymbolInfoMap

In declarative rewrite rules, a symbol can be bound to op arguments or
results in the source pattern, and it can be bound to op results in t

NFC: Refactoring PatternSymbolResolver into SymbolInfoMap

In declarative rewrite rules, a symbol can be bound to op arguments or
results in the source pattern, and it can be bound to op results in the
result pattern. This means given a symbol in the pattern, it can stands
for different things: op operand, op attribute, single op result,
op result pack. We need a better way to model this complexity so that
we can handle according to the specific kind a symbol corresponds to.

Created SymbolInfo class for maintaining the information regarding a
symbol. Also created a companion SymbolInfoMap class for a map of
such symbols, providing insertion and querying depending on use cases.

PiperOrigin-RevId: 262675515

show more ...

Emit matchAndRewrite() for declarative rewrite rules

Previously we are emitting separate match() and rewrite()
methods, which requires conveying a match state struct
in a unique_ptr across these two

Emit matchAndRewrite() for declarative rewrite rules

Previously we are emitting separate match() and rewrite()
methods, which requires conveying a match state struct
in a unique_ptr across these two methods. Changing to
emit matchAndRewrite() simplifies the picture.

PiperOrigin-RevId: 261906804

show more ...

NFC: Implement OwningRewritePatternList as a class instead of a using directive.

This allows for proper forward declaration, as opposed to leaking the internal implementation via a using directive.

NFC: Implement OwningRewritePatternList as a class instead of a using directive.

This allows for proper forward declaration, as opposed to leaking the internal implementation via a using directive. This also allows for all pattern building to go through 'insert' methods on the OwningRewritePatternList, replacing uses of 'push_back' and 'RewriteListBuilder'.

PiperOrigin-RevId: 261816316

show more ...

Replace the verifyUnusedValue directive with HasNoUseOf constraint

verifyUnusedValue is a bit strange given that it is specified in a
result pattern but used to generate match statements. Now we are

Replace the verifyUnusedValue directive with HasNoUseOf constraint

verifyUnusedValue is a bit strange given that it is specified in a
result pattern but used to generate match statements. Now we are
able to support multi-result ops better, we can retire it and replace
it with a HasNoUseOf constraint. This reduces the number of mechanisms.

PiperOrigin-RevId: 261166863

show more ...

Fix support for auxiliary ops in declarative rewrite rules

We allow to generate more ops than what are needed for replacing
the matched root op. Only the last N static values generated are
used as r

Fix support for auxiliary ops in declarative rewrite rules

We allow to generate more ops than what are needed for replacing
the matched root op. Only the last N static values generated are
used as replacement; the others serve as auxiliary ops/values for
building the replacement.

With the introduction of multi-result op support, an op, if used
as a whole, may be used to replace multiple static values of
the matched root op. We need to consider this when calculating
the result range an generated op is to replace.

For example, we can have the following pattern:

```tblgen
def : Pattern<(ThreeResultOp ...),
[(OneResultOp ...), (OneResultOp ...), (OneResultOp ...)]>;

// Two op to replace all three results
def : Pattern<(ThreeResultOp ...),
[(TwoResultOp ...), (OneResultOp ...)]>;

// One op to replace all three results
def : Pat<(ThreeResultOp ...), (ThreeResultOp ...)>;

def : Pattern<(ThreeResultOp ...),
[(AuxiliaryOp ...), (ThreeResultOp ...)]>;
```
PiperOrigin-RevId: 261017235

show more ...

RewriterGen: properly handle zero-result ops

RewriterGen was emitting invalid C++ code if the pattern required to create a
zero-result operation due to the absence of a special case that would avoid

RewriterGen: properly handle zero-result ops

RewriterGen was emitting invalid C++ code if the pattern required to create a
zero-result operation due to the absence of a special case that would avoid
generating a spurious comma. Handle this case. Also add rewriter tests for
zero-argument operations.

PiperOrigin-RevId: 260576998

show more ...