| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
constraints, to guard against potential over-approximation from projection.
--
PiperOrigin-RevId: 247431201
|
|
|
|
|
|
|
|
| |
ability to stream an attribute into a Diagnostic.
--
PiperOrigin-RevId: 247359911
|
|
|
|
|
|
|
|
| |
interface with llvm::SourceMgr. This lowers the barrier of entry for tools to get rich diagnostic handling when using llvm::SourceMgr.
--
PiperOrigin-RevId: 247358610
|
|
|
|
|
|
|
|
| |
class serves the same purpose as TypeBase, and thus the duplicated functionality has been split into a new support class 'StorageUserBase'.
--
PiperOrigin-RevId: 247358373
|
|
|
|
|
|
|
|
| |
types. This has the added benefit of removing type redundancy from the pretty form. As a consequence, IntegerAttr/FloatAttr will now always print the type even if it is i64/f64.
--
PiperOrigin-RevId: 247295828
|
|
|
|
|
|
|
|
| |
This also adds support for streaming in ranges(e.g. ArrayRef) into a diagnostic with an optional element delimiter.
--
PiperOrigin-RevId: 247239436
|
|
|
|
|
|
|
|
| |
identifiers for class types. This replaces the duplicated functionality of AnalysisID/PassID/etc.
--
PiperOrigin-RevId: 247237835
|
|
|
|
|
|
|
|
| |
the custom operation parsers) to use it instead of bool.
--
PiperOrigin-RevId: 246955523
|
|
|
|
|
|
|
|
|
|
| |
This closely mirrors the llvm fcmp instruction, defining 16 different predicates
Constant folding is unsupported for NaN and Inf because there's no way to represent those as constants at the moment
--
PiperOrigin-RevId: 246932358
|
|
|
|
|
|
|
|
|
|
| |
and, transitively, access to the context.
This also fixes a bug where FunctionAttrs were not being remapped for function and function argument attributes.
--
PiperOrigin-RevId: 246876924
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into more general support for attribute aliases.
`#` alias `=` attribute-value
This also allows for dialects to define aliases for attributes in the AsmPrinter. The printer supports two types of attribute aliases, 'direct' and 'kind'.
* Direct aliases are synonymous with the current support for type aliases, i.e. this maps an alias to a specific instance of an attribute.
// A direct alias ("foo_str") for the string attribute "foo".
#foo_str = "foo"
* Kind aliases generates unique names for all instances of a given attribute kind. The generated aliases are of the form: `alias[0-9]+`.
// A kind alias ("strattr") for all string attributes could generate.
#strattr0 = "foo"
#strattr1 = "bar"
...
#strattrN = "baz"
--
PiperOrigin-RevId: 246851916
|
|
|
|
|
|
|
|
| |
dialects (Affine/Standard/etc.) by using the new stream interface instead of Twine.
--
PiperOrigin-RevId: 246842016
|
|
|
|
|
|
|
|
| |
This can be removed in C++17.
--
PiperOrigin-RevId: 246827022
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The generic form of operations currently supports optional regions to be
located after the operation type. As we are going to add a type to each
region in a leading position in the region syntax, similarly to functions, it
becomes ambiguous to have regions immediately after the operation type. Put
regions between operands the optional list of successors in the generic
operation syntax and wrap them in parentheses. The effect on the exisitng IR
syntax is minimal since only three operations (`affine.for`, `affine.if` and
`gpu.kernel`) currently use regions.
--
PiperOrigin-RevId: 246787087
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 246671765
|
|
|
|
|
|
|
|
|
|
| |
caused by a bug in gcc versions < 7.0.
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56480)
--
PiperOrigin-RevId: 246664463
|
|
|
|
|
|
|
|
| |
This trait only works for tensor and vector types at the moment, verifying that the element type of an op with only tensor and vector types match. Added a unit test for it as there is no op currently in core that uses this trait.
--
PiperOrigin-RevId: 246661697
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 246614498
|
|
|
|
|
|
|
|
| |
OpAsmPrinter. These should go through attributes like most everything else.
--
PiperOrigin-RevId: 246589682
|
|
|
|
|
|
|
|
| |
optional. This allows for the ability to exclusively use the new diagnostic interface without breaking all of the existing usages. Several diagnostics emitted in lib/IR have been updated to make use of this functionality.
--
PiperOrigin-RevId: 246546044
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 246546015
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Notes are a way to add additional context to a diagnostic, but don't really make sense as standalone diagnostics. Moving forward, notes will no longer be able to be constructed directly and must be attached to a parent Diagnostic.
Notes can be attached via `attachNote`:
auto diag = ...;
diag.attachNote() << "This is a note";
--
PiperOrigin-RevId: 246545971
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InFlightDiagnostic.
The Diagnostic class contains all of the information necessary to report a diagnostic to the DiagnosticEngine. It should generally not be constructed directly, and instead used transitively via InFlightDiagnostic. A diagnostic is currently comprised of several different elements:
* A severity level.
* A source Location.
* A list of DiagnosticArguments that help compose and comprise the output message.
* A DiagnosticArgument represents any value that may be part of the diagnostic, e.g. string, integer, Type, Attribute, etc.
* Arguments can be added to the diagnostic via the stream(<<) operator.
* (In a future cl) A list of attached notes.
* These are in the form of other diagnostics that provide supplemental information to the main diagnostic, but do not have context on their own.
The InFlightDiagnostic class represents an RAII wrapper around a Diagnostic that is set to be reported with the diagnostic engine. This allows for the user to modify a diagnostic that is inflight. The internally wrapped diagnostic can be reported directly or automatically upon destruction.
These classes allow for more natural composition of diagnostics by removing the restriction that the message of a diagnostic is comprised of a single Twine. They should also allow for nice incremental improvements to the diagnostics experience in the future, e.g. formatv style diagnostics.
Simple Example:
emitError(loc, "integer bitwidth is limited to " + Twine(IntegerType::kMaxWidth) + " bits");
emitError(loc) << "integer bitwidth is limited to " << IntegerType::kMaxWidth << " bits";
--
PiperOrigin-RevId: 246526439
|
|
|
|
|
|
|
|
| |
AttributeSupport.h in preparation for them to be used by dialect defined attributes.
--
PiperOrigin-RevId: 246385860
|
|
|
|
|
|
|
|
| |
when constructing a new storage.
--
PiperOrigin-RevId: 246356767
|
|
|
|
|
|
|
|
| |
functionality needed to separate notes from remarks. It also provides a starting point to start building out better remark infrastructure.
--
PiperOrigin-RevId: 246175216
|
|
|
|
|
|
|
|
| |
'DiagnosticEngine' and move the diagnostic handler support and final diagnostic emission from the MLIRContext to it.
--
PiperOrigin-RevId: 246163897
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL adds a primitive tiling pass for Linalg.
The tiling pass uses the loopToOperandRangesMaps property which should be ideally Tablegen'd and in-class.
The tiling specification uses 0 as a convention to skip loops that should not be tiled.
Tiling proceeds in 3 steps, for each op:
1. Pad tile sizes with 0 to match the number of loops, this simplifies the implementation and avoids affine map manipulations to align dimensions.
2. Create loop ranges that represent the min/max/step by which to iterate. This should be later complemented by a range intersection to avoid the out-of-bounds case.
3. Map the loop ranges to view ranges in order to create subviews on which the op can be called.
Relevant utility and helper functions are added separately that support writing the transformation in a declarative fashion.
Simplifying assumptions are made for now on the views and the ranges that are constructed
in the function and are not passed as function arguments. This restriction will be lifted
in the future.
--
PiperOrigin-RevId: 246124419
|
|
|
|
|
|
|
|
| |
subclass is no longer necessary.
--
PiperOrigin-RevId: 246061024
|
|
|
|
|
|
|
|
| |
provide a type explicitly, the type is defaulted to NoneType.
--
PiperOrigin-RevId: 246021088
|
|
|
|
|
|
|
|
| |
coded in the MLIRContext. This allows for attributes to be uniqued similarly to types. This is the second step towards allowing dialects to define attributes.
--
PiperOrigin-RevId: 245974705
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 245844236
|
|
|
|
|
|
|
|
| |
The missing dependency breaks linking on Linux.
--
PiperOrigin-RevId: 245773637
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Define a new dialect related to GPU kernels. Currently, it only contains a
single operation for launching a kernel on a three-dimensional grid of thread
blocks, following a model similar to that of CUDA. In particular, the body of
the kernel contains operations executed by each thread and uses region
arguments to accept thread and block identifiers (similar to how the loop body
region accepts the induction value).
--
PiperOrigin-RevId: 245713728
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, fold such operations. This way callers don't need to conditionally create cast operations depending on if a value already has the target type.
Also, introduce areCastCompatible to allow cast users to verify that the generated op will be valid before creating the operation.
TESTED with unit tests
--
PiperOrigin-RevId: 245606133
|
|
|
|
|
|
|
|
|
|
| |
none-type ::= `none`
The `none` type is a unit type, i.e. a type with exactly one possible value, where its value does not have a defined dynamic representation.
--
PiperOrigin-RevId: 245599248
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since SDBM expressions are a subset of affine expressions, they can be
converted to affine expressions in a straightforward way. The inverse
conversion may fail when the affine expression is not an SDBM. Implement the
inverse convresion assuming affine expressions are simplified and
canonicalizied, detect subtractive and multiplicative forms of the stripe
operation.
--
PiperOrigin-RevId: 245494735
|
|
|
|
|
|
|
|
|
|
|
| |
Striped difference-bound matrix expressions are a subset of affine expressions
supporting low-complexity algorithms that can be useful for loop
transformations. This introduces the basic data data structures for building
such expressions and unique'ing them in a MLIRContext.
--
PiperOrigin-RevId: 245380206
|
|
|
|
|
|
|
|
| |
TypeUniquer into its own class 'StorageUniquer'. This is the first step in supporting dialect extensible attributes.
--
PiperOrigin-RevId: 245358744
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A unit attribute is an attribute that represents a value of `unit` type. The
`unit` type allows only one value forming a singleton set. This attribute value
is used to represent attributes that only have meaning from their existence.
One example of such an attribute could be the `swift.self` attribute. This attribute indicates that a function parameter is the self/context
parameter. It could be represented as a boolean attribute(true or false), but a
value of false doesn't really bring any value. The parameter either is the
self/context or it isn't.
```mlir {.mlir}
// A unit attribute defined with the `unit` value specifier.
func @verbose_form(i1 {unitAttr : unit})
// A unit attribute can also be defined without the `unit` value specifier.
func @simple_form(i1 {unitAttr})
```
--
PiperOrigin-RevId: 245254045
|
|
|
|
|
|
|
|
|
|
| |
with shape
{}.
--
PiperOrigin-RevId: 245104548
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add member functions for Regions to query if another Region is a ancestor. The
implementation is naive and traverses all parent regions performing one-to-one
comparisons. As a side effect, this introduces `getContainingRegion` function
for Operations and Values to return the Region in which they are defined, and
for Regions to return the "parent" region if any.
--
PiperOrigin-RevId: 245057980
|
|
|
|
|
|
|
|
|
|
| |
Extract common code from getAffineSymbolExpr and getAffineConstantExpr into a
utility function safeGetOrCreate, similarly to the existing overloads for sets
and maps. The position in the vector is used as indexing key. NFC.
--
PiperOrigin-RevId: 244820859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During the pattern rewrite, if the function is changed, i.e. ops created,
deleted or swapped, the pattern rewriter needs to re-scan the function entirely
and apply the patterns again, so the patterns whose root ops have been popped
out from the working list nor an immediate users of the changed ops can be
reconsidered.
A command line flag is added to set the max number of iterations rescanning the
function for pattern match. If the rewrite doesn' converge after this number,
this compiling will continue and the result can be sub-optimal.
One unit test is updated because this change fixed the missing optimization opportunities.
--
PiperOrigin-RevId: 244754190
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 244488612
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The per-layer format is now like:
!quant.uniform<i8<-8:7>:f32, 9.987200e-01:127>
and per-axis is:
!quant.uniform<i8:f32:1, {2.0e+2,0.99872:120}>
I used the following sed script to update the unit tests (invoked with commands like `sed -i -r -f fix_quant.sed $(find . -name '*.mlir')`).
---
# Per-layer
s|\!quant<"uniform\[([iu][0-9]+):([fb]+[0-9]+)\]\{([^\}]+)\}\s*">|!quant.uniform<\1:\2, \3>|g
s|\!quant<"uniform\[([iu][0-9]+)\(([^\)]+)\):([fb]+[0-9]+)\]\{([^\}]+)\}\s*">|!quant.uniform<\1<\2>:\3, \4>|g
# Per-axis
s|\!quant<"uniform\[([iu][0-9]+):([fb]+[0-9]+)(:[0-9]+)?\]\{([^\}]+)\}\s*">|!quant.uniform<\1:\2\3, {\4}>|g
s|\!quant<"uniform\[([iu][0-9]+)\(([^\)]+)\):([fb]+[0-9]+)(:[0-9]+)?\]\{([^\}]+)\}\s*">|!quant.uniform<\1<\2>:\3\4, {\5}>|g
---
I fixed up the one file of error cases manually.
Since this is a one time syntax fix, I am not persisting the script anywhere.
--
PiperOrigin-RevId: 244425331
|
|
|
|
|
|
| |
--
PiperOrigin-RevId: 243904869
|
|
|
|
|
|
|
|
|
|
| |
Fixes test in opt mode.
Closes: tensorflow/mlir#17.
--
PiperOrigin-RevId: 243711043
|
|
|
|
|
|
|
|
|
| |
other characters within the <>'s now that we can. This will allow quantized
types to use the pretty syntax (among others) after a few changes.
--
PiperOrigin-RevId: 243521268
|
|
|
|
|
|
|
|
|
| |
This addresses the "suggest parentheses around ‘&&’ within ‘||’
[-Wparentheses]" compiler warnings.
--
PiperOrigin-RevId: 242868670
|