| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
making the IR dumps much nicer.
This is part 2/3 of the path to making dialect types more nice. Part 3/3 will
slightly generalize the set of characters allowed in pretty types and make it
more principled.
--
PiperOrigin-RevId: 242249955
|
|
|
|
|
|
|
|
| |
This avoids the need to load all of the values from a DenseElementsAttr inorder to process them.
--
PiperOrigin-RevId: 242212741
|
|
|
|
|
|
|
|
|
| |
I32/I64/F32/F64/Str array attributes are commonly used in ops. It helps
to have handy methods for them.
--
PiperOrigin-RevId: 242170569
|
|
|
|
|
|
|
|
| |
FunctionAttr::dropFunctionReference.
--
PiperOrigin-RevId: 242050934
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 242031201
|
|
|
|
|
|
|
|
| |
and rename walkPostOrder to walk.
--
PiperOrigin-RevId: 241965239
|
|
|
|
|
|
|
|
|
| |
This came up in a review of the tutorial, it was suggested that "opaque" is more
descriptive than "unknown" here.
--
PiperOrigin-RevId: 241832927
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, we only make the initial address aligned with 64-bit address but
allocate the buffer with the real size. This can cause issue when we extract
the value by the `readBits` method, which needs to read the memory in the
granularity of APINT_WORD_SIZE. In this CL, we rounded the allocation size to
the multiplies of APINT_WORD_SIZE to fix the issue.
--
PiperOrigin-RevId: 241816656
|
|
|
|
|
|
|
|
| |
instead of bool. This updates Function::emitError to return LogicalResult as well.
--
PiperOrigin-RevId: 241598892
|
|
|
|
|
|
|
|
| |
bool. This also changes the return of Operation::emitError/emitOpError to LogicalResult as well.
--
PiperOrigin-RevId: 241588075
|
|
|
|
|
|
|
|
| |
defining Operations if any, otherwise an unknown location
--
PiperOrigin-RevId: 241354085
|
|
|
|
|
|
|
|
| |
This CL fixes the parser and printer to support the 0-d tensor type attributes.
--
PiperOrigin-RevId: 241345329
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unregistered operations. This flag is off by default and can be toggled via the 'allowUnknownOperations(...)' method. This means that moving forward an error will be emitted for unknown operations if the dialect does not explicitly allow it.
Example:
func @unknown_std_op() {
%0 = "std.foo_bar_op"() : () -> index
return
}
Will result in:
error: unregistered operation 'std.foo_bar_op' found in dialect ('std') that does not allow unknown operations
--
PiperOrigin-RevId: 241266009
|
|
|
|
|
|
|
|
| |
some comments to make it clear that 'name' refers to the dialect namespace.
--
PiperOrigin-RevId: 241103116
|
|
|
|
|
|
|
|
|
| |
have no standard ops for working with these yet, this is simply enough to
represent and round trip them in the printer and parser.
--
PiperOrigin-RevId: 241102728
|
|
|
|
|
|
|
|
|
| |
* Add initial version of build files;
* Update README with instructions to download and build MLIR from github;
--
PiperOrigin-RevId: 241102092
|
|
|
|
|
|
|
|
| |
guarantee that the namespace of a dialect can be used a unique key.
--
PiperOrigin-RevId: 241049578
|
|
|
|
|
|
|
|
| |
already have access to the context via Dialect::getContext.
--
PiperOrigin-RevId: 241047077
|
|
|
|
|
|
|
|
| |
return instead of bool.
--
PiperOrigin-RevId: 241045568
|
|
|
|
|
|
|
|
|
|
|
|
| |
Dialect conversion currently clones the operations that did not match any
pattern. This includes cloning any regions that belong to these operations.
Instead, apply conversion recursively to the nested regions.
Note that if an operation matched one of the conversion patterns, it is up to
the pattern rewriter to fill in the regions of the converted operation. This
may require calling back to the converter and is left for future work.
PiperOrigin-RevId: 240872410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
result now contains the number of results that it refers to if the number of results is greater than 1.
Example:
%call:2 = call @multi_return() : () -> (f32, i32)
use(%calltensorflow/mlir#0, %calltensorflow/mlir#1)
This cl also adds parser support for uniquely named result values. This means that a test writer can now write something like:
%foo, %bar = call @multi_return() : () -> (f32, i32)
use(%foo, %bar)
Note: The printer will still print the collapsed form.
PiperOrigin-RevId: 240860058
|
|
|
|
| |
PiperOrigin-RevId: 240814651
|
|
|
|
| |
PiperOrigin-RevId: 240777521
|
|
|
|
|
|
| |
The Pass base class is providing a convenience getContext() accessor.
PiperOrigin-RevId: 240634961
|
|
|
|
| |
PiperOrigin-RevId: 240569775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to legacy reasons (ML/CFG function separation), regions in affine control
flow operations require contained blocks not to have terminators. This is
inconsistent with the notion of the block and may complicate code motion
between regions of affine control operations and other regions.
Introduce `affine.terminator`, a special terminator operation that must be used
to terminate blocks inside affine operations and transfers the control back to
he region enclosing the affine operation. For brevity and readability reasons,
allow `affine.for` and `affine.if` to omit the `affine.terminator` in their
regions when using custom printing and parsing format. The custom parser
injects the `affine.terminator` if it is missing so as to always have it
present in constructed operations.
Update transformations to account for the presence of terminator. In
particular, most code motion transformation between loops should leave the
terminator in place, and code motion between loops and non-affine blocks should
drop the terminator.
PiperOrigin-RevId: 240536998
|
|
|
|
| |
PiperOrigin-RevId: 240462910
|
|
|
|
|
|
| |
This is step 2/N to renaming Instruction to Operation.
PiperOrigin-RevId: 240459216
|
|
|
|
|
|
|
|
| |
usages of Instruction will still refer to a typedef in the interim.
This is step 1/N to renaming Instruction to Operation.
PiperOrigin-RevId: 240431520
|
|
|
|
|
|
| |
operation is associated with, or nullptr if the associated dialect has not been registered.
PiperOrigin-RevId: 240402300
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, regions can only be constructed by passing in a `Function` or an
`Instruction` pointer referencing the parent object, unlike `Function`s or
`Instruction`s themselves that can be created without a parent. It leads to a
rather complex flow in operation construction where one has to create the
operation first before being able to work with its regions. It may be
necessary to work with the regions before the operation is created. In
particular, in `build` and `parse` functions that are executed _before_ the
operation is created in cases where boilerplate region manipulation is required
(for example, inserting the hypothetical default terminator in affine regions).
Allow creating standalone regions. Such regions are meant to own a list of
blocks and transfer them to other regions on demand.
Each instruction stores a fixed number of regions as trailing objects and has
ownership of them. This decreases the size of the Instruction object for the
common case of instructions without regions. Keep this behavior intact. To
allow some flexibility in construction, make OperationState store an owning
vector of regions. When the Builder creates an Instruction from
OperationState, the bodies of the regions are transferred into the
instruction-owned regions to minimize copying. Thus, it becomes possible to
fill standalone regions with blocks and move them to an operation when it is
constructed, or move blocks from a region to an operation region, e.g., for
inlining.
PiperOrigin-RevId: 240368183
|
|
|
|
|
|
|
|
|
|
| |
This is done by adding a new 'matchAndRewrite' function to RewritePattern that performs the match and rewrite in one step. The default behavior simply calls into the existing 'match' and 'rewrite' functions. The 'PatternMatcher' class has now been specialized for RewritePatterns and has been rewritten to make use of the new matchAndRewrite functionality.
This combined match/rewrite functionality allows simplifying the majority of existing RewritePatterns, as they do not benefit from separate match and rewrite functions.
Some of the existing canonicalization patterns in StandardOps have been modified to take advantage of this functionality.
PiperOrigin-RevId: 240187856
|
|
|
|
| |
PiperOrigin-RevId: 240084937
|
|
|
|
| |
PiperOrigin-RevId: 240083489
|
|
|
|
|
|
| |
OpPointer.
PiperOrigin-RevId: 240044712
|
|
|
|
| |
PiperOrigin-RevId: 239976764
|
|
|
|
|
|
| |
*Op classes. This is a net reduction by almost 400LOC.
PiperOrigin-RevId: 239972443
|
|
|
|
| |
PiperOrigin-RevId: 239958211
|
|
|
|
|
|
|
|
|
|
| |
tblgen be non-const. This requires introducing some const_cast's at the
moment, but those (and lots more stuff) will disappear in subsequent patches.
This significantly simplifies those patches because the various tblgen op emitters
get adjusted.
PiperOrigin-RevId: 239954566
|
|
|
|
|
|
| |
DenseElementsAttr when allocating an empty array buffer.
PiperOrigin-RevId: 239926824
|
|
|
|
|
|
| |
This also eliminates some incorrect reinterpret_cast logic working around it, and numerous const-incorrect issues (like block argument iteration).
PiperOrigin-RevId: 239712029
|
|
|
|
| |
PiperOrigin-RevId: 239642194
|
|
|
|
|
|
| |
from Function.
PiperOrigin-RevId: 239638635
|
|
|
|
| |
PiperOrigin-RevId: 239616595
|
|
|
|
|
|
| |
Module'. NFC.
PiperOrigin-RevId: 239532885
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
merely provides a common mechanism for representing tuples in MLIR. It is up to dialect authors to provides operations for manipulating them, e.g. extract_tuple_element.
TupleType has the following form:
tuple-type ::= `tuple` `<` (type (`,` type)*)? `>`
Example:
// Empty tuple.
tuple<>
// Single element.
tuple<i32>
// Multi element.
tuple<i32, tuple<f32>, i16>
PiperOrigin-RevId: 239226021
|
|
|
|
|
|
| |
NFC.
PiperOrigin-RevId: 239197784
|
|
|
|
| |
PiperOrigin-RevId: 238814769
|
|
|
|
|
|
| |
identifier uniquing thread safe. This also adds a general purpose 'contextMutex' to protect access to the rest of the miscellaneous parts of the MLIRContext, e.g. diagnostics, dialect registration, etc. This is step 5/5 of making the MLIRContext thread-safe.
PiperOrigin-RevId: 238516697
|
|
|
|
|
|
| |
using the locationAllocator. This is step 4/N to making MLIRContext thread-safe.
PiperOrigin-RevId: 238516646
|