forked from OSchip/llvm-project
[mlir][doc] fix typos.
This fixes some typos in OpDefinitions.md and DeclarativeRewrites.md, and wrap function/class names in backticks. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D110582
This commit is contained in:
parent
993555beb8
commit
a4bccf7afd
|
@ -355,7 +355,7 @@ def OneAttrOp : Op<"one_attr_op"> {
|
|||
We can write a C++ helper function:
|
||||
|
||||
```c++
|
||||
Attribute createArrayAttr(Builder &builder, Attribute a, Attribute b) {
|
||||
ArrayAttr createArrayAttr(Builder &builder, Attribute a, Attribute b) {
|
||||
return builder.getArrayAttr({a, b});
|
||||
}
|
||||
```
|
||||
|
@ -405,15 +405,15 @@ def : Pat<(OneAttrOp (NativeCodeCall<"Foo($_self, &$0)"> I32Attr:$val)),
|
|||
```
|
||||
|
||||
In the above, `$_self` is substituted by the defining operation of the first
|
||||
operand of OneAttrOp. Note that we don't support binding name to NativeCodeCall
|
||||
in the source pattern. To carry some return values from helper function, put the
|
||||
operand of OneAttrOp. Note that we don't support binding name to `NativeCodeCall`
|
||||
in the source pattern. To carry some return values from a helper function, put the
|
||||
names (constraint is optional) in the parameter list and they will be bound to
|
||||
the variables with correspoding type. Then these named must be either passed by
|
||||
reference or a pointer to variable used as argument so that the matched value
|
||||
the variables with correspoding type. Then these names must be either passed by
|
||||
reference or pointer to the variable used as argument so that the matched value
|
||||
can be returned. In the same example, `$val` will be bound to a variable with
|
||||
`Attribute` type(as `I32Attr`) and the type of the second argument in Foo()
|
||||
`Attribute` type (as `I32Attr`) and the type of the second argument in `Foo()`
|
||||
could be `Attribute&` or `Attribute*`. Names with attribute constraints will be
|
||||
captured as Attributes while everything else will be treated as Value.
|
||||
captured as `Attribute`s while everything else will be treated as `Value`s.
|
||||
|
||||
Positional placeholders will be substituted by the `dag` object parameters at
|
||||
the `NativeCodeCall` use site. For example, if we define `SomeCall :
|
||||
|
@ -440,13 +440,13 @@ def : Pattern<(TwoResultOp $attr1, $attr2),
|
|||
|
||||
```
|
||||
|
||||
Use `NativeCodeCallVoid` for case has no return value.
|
||||
Use `NativeCodeCallVoid` for cases with no return value.
|
||||
|
||||
The correct number of returned value specified in NativeCodeCall is important.
|
||||
It will be used to verify the consistency of the number of result values.
|
||||
Additionally, `mlir-tblgen` will try to capture the return value of
|
||||
NativeCodeCall in the generated code so that it will trigger a later compilation
|
||||
error if a NativeCodeCall that doesn't return a result isn't labeled with 0
|
||||
It will be used to verify the consistency of the number of return values.
|
||||
Additionally, `mlir-tblgen` will try to capture the return values of
|
||||
`NativeCodeCall` in the generated code so that it will trigger a later compilation
|
||||
error if a `NativeCodeCall` that doesn't return any result isn't labeled with 0
|
||||
returns.
|
||||
|
||||
##### Customizing entire op building
|
||||
|
@ -531,9 +531,9 @@ def ThreeResultOp : Op<"three_result_op"> {
|
|||
let arguments = (ins ...);
|
||||
|
||||
let results = (outs
|
||||
AnyTensor:$op_output1,
|
||||
AnyTensor:$op_output2,
|
||||
AnyTensor:$op_output3
|
||||
AnyTensor:$output1,
|
||||
AnyTensor:$output2,
|
||||
AnyTensor:$output3
|
||||
);
|
||||
}
|
||||
|
||||
|
@ -542,7 +542,7 @@ def : Pattern<(ThreeResultOp:$results ...),
|
|||
```
|
||||
|
||||
In the above pattern we bind `$results` to all the results generated by
|
||||
`ThreeResultOp` and references its `$input1` and `$input3` later in the result
|
||||
`ThreeResultOp` and references its `$output1` and `$output3` later in the result
|
||||
patterns.
|
||||
|
||||
We can also bind a symbol and reference one of its specific result at the same
|
||||
|
@ -728,7 +728,7 @@ In the above pattern, the generated `LocDst2Op` will use the matched location of
|
|||
### `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:
|
||||
all of its uses with a captured value. It is of the following syntax:
|
||||
|
||||
```tablegen
|
||||
(replaceWithValue $symbol)
|
||||
|
|
|
@ -1111,7 +1111,7 @@ is used. They serve as "hooks" to the enclosing environment. This includes
|
|||
information of the current operation.
|
||||
* `$_self` will be replaced with the entity this predicate is attached to.
|
||||
E.g., `BoolAttr` is an attribute constraint that wraps a
|
||||
`CPred<"$_self.isa<BoolAttr>()">`. Then for `F32Attr:$attr`,`$_self` will be
|
||||
`CPred<"$_self.isa<BoolAttr>()">`. Then for `BoolAttr:$attr`,`$_self` will be
|
||||
replaced by `$attr`. For type constraints, it's a little bit special since
|
||||
we want the constraints on each type definition reads naturally and we want
|
||||
to attach type constraints directly to an operand/result, `$_self` will be
|
||||
|
|
Loading…
Reference in New Issue