| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
BumpPtrAllocator and SmartMutex to make them thread-safe. This is step 3/N to making MLIRContext thread-safe.
PiperOrigin-RevId: 238516596
|
|
|
|
|
|
| |
thread-safe. This is step 2/N to making the MLIRContext thread-safe.
PiperOrigin-RevId: 238516542
|
|
|
|
|
|
| |
NamedAttributeList. This avoids the need to unique an attribute list if one already exists, e.g. when cloning an existing instruction.
PiperOrigin-RevId: 238512499
|
|
|
|
|
|
| |
redundant creation of IntegerAttrs and IndexType. This becomes a much bigger performance issue when MLIRContext is thread-safe; as each unnecessary call may need to lock a mutex.
PiperOrigin-RevId: 238484632
|
|
|
|
|
|
| |
NFC. This is step 1/n to specifying regions as parts of any operation.
PiperOrigin-RevId: 238472370
|
|
|
|
|
|
| |
thread-safe. This is step 1/N to making the MLIRContext thread-safe.
PiperOrigin-RevId: 238037814
|
|
|
|
| |
PiperOrigin-RevId: 237719658
|
|
|
|
|
|
| |
classes. This removes the need for derived types to define a static typeID field.
PiperOrigin-RevId: 237482890
|
|
|
|
|
|
| |
likely more helpful to the user when it fires
PiperOrigin-RevId: 237170067
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a bug: previously, during conversion function argument
attributes were neither beings passed through nor converted. This fix
extends DialectConversion to allow for simultaneous conversion of the
function type and the argument attributes.
This was important when lowering MLIR to LLVM where attribute
information (e.g. noalias) needs to be preserved in MLIR(LLVMDialect).
Longer run it seems reasonable that we want to convert both the
function attribute and its type and the argument attributes, but that
requires a small refactoring in Function.h to aggregate these three
fields in an inner struct, which will require some discussion.
PiperOrigin-RevId: 236709409
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dialect attribute derives its context from a specific dialect, whereas a dependent attribute derives context from what it is attached to. Following this, we now enforce that functions and function arguments may only contain dialect specific attributes. These are generic entities and cannot provide any specific context for a dependent attribute.
Dialect attributes are defined as:
dialect-namespace `.` attr-name `:` attribute-value
Dialects can override any of the following hooks to verify the validity of a given attribute:
* verifyFunctionAttribute
* verifyFunctionArgAttribute
* verifyInstructionAttribute
PiperOrigin-RevId: 236507970
|
|
|
|
|
|
|
|
| |
creating an operation
This is more friendly for the user than a raw segfault
PiperOrigin-RevId: 236504102
|
|
|
|
|
|
| |
The only thing left in BuiltinOps are the core MLIR types. The standard types can't be moved because they are referenced within the IR directory, e.g. in things like Builder.
PiperOrigin-RevId: 236403665
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The attribute dictionaries are printed after the final block list for both operations:
for %i = 0 to 10 {
...
} {some_attr: true}
if () : () () {
...
} {some_attr: true}
if () : () () {
...
} else {
...
} {some_attr: true}
PiperOrigin-RevId: 236346983
|
|
|
|
|
|
| |
(Instruction|Function)::setAttr(StringRef, Attribute) to simplify attribute manipulation.
PiperOrigin-RevId: 236222504
|
|
|
|
|
|
|
|
|
|
| |
is printed after the argument type:
func @arg_attrs(i32 {arg_attr: 10})
func @arg_attrs(%arg0: i32 {arg_attr: 10})
PiperOrigin-RevId: 236136830
|
|
|
|
| |
PiperOrigin-RevId: 236013669
|
|
|
|
|
|
| |
between Function and Instruction.
PiperOrigin-RevId: 235830304
|
|
|
|
|
|
| |
This essentially enforces the parsing rules upon their names.
PiperOrigin-RevId: 235818842
|
|
|
|
|
|
| |
names starting with ':'.
PiperOrigin-RevId: 235774810
|
|
|
|
| |
PiperOrigin-RevId: 235746553
|
|
|
|
|
|
|
| |
- remove stale comments + cleanup
- drop MLIRContext * field from expr flattener
PiperOrigin-RevId: 235621178
|
|
|
|
|
|
| |
Dialect class.
PiperOrigin-RevId: 235589945
|
|
|
|
|
|
| |
DenseFPElementsAttr with an array of APFloat.
PiperOrigin-RevId: 235581794
|
|
|
|
|
|
| |
Deletes specialized mechanism for registering constant folding hook and uses dialect hooks registration mechanism instead.
PiperOrigin-RevId: 235535410
|
|
|
|
|
|
| |
OpaqueElementsAttr.
PiperOrigin-RevId: 235533283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Analysis - NFC
- refactor AffineExprFlattener (-> SimpleAffineExprFlattener) so that it
doesn't depend on FlatAffineConstraints, and so that FlatAffineConstraints
could be moved out of IR/; the simplification that the IR needs for
AffineExpr's doesn't depend on FlatAffineConstraints
- have AffineExprFlattener derive from SimpleAffineExprFlattener to use for
all Analysis/Transforms purposes; override addLocalFloorDivId in the derived
class
- turn addAffineForOpDomain into a method on FlatAffineConstraints
- turn AffineForOp::getAsValueMap into an AffineValueMap ctor
PiperOrigin-RevId: 235283610
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce support for binding MLIR functions as constant expressions. Standard
constant operation supports functions as possible constant values.
Provide C APIs to look up existing named functions in an MLIR module and expose
them to the Python bindings. Provide Python bindings to declare a function in
an MLIR module without defining it and to add a definition given a function
declaration. These declarations are useful when attempting to link MLIR
modules with, e.g., the standard library.
Introduce EDSC support for direct and indirect calls to other MLIR functions.
Internally, an indirect call is always emitted to leverage existing support for
delayed construction of MLIR Values using EDSC Exprs. If the expression is
bound to a constant function (looked up or declared beforehand), MLIR constant
folding will be able to replace an indirect call by a direct call. Currently,
only zero- and one-result functions are supported since we don't have support
for multi-valued expressions in EDSC.
Expose function calling interface to Python bindings on expressions by defining
a `__call__` function accepting a variable number of arguments.
PiperOrigin-RevId: 234959444
|
|
|
|
|
|
| |
This enables lit testing of passes that add internal attributes.
PiperOrigin-RevId: 234809949
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent change made ConstantOp::build accept a NumericAttr or assert that a
generic Attribute is in fact a NumericAttr. The rationale behind the change
was that NumericAttrs have a type that can be used as the result type of the
constant operation. FunctionAttr also has a type, and it is valid to construct
function-typed constants as exercised by the parser.mlir test. Relax
ConstantOp::build back to take a generic Attribute. In the overload that only
takes an attribute, assert that the Attribute is either a NumericAttr or a
FunctionAttr, because it is necessary to extract the type. In the overload
that takes both type type and the attribute, delegate the attribute type
checking to ConstantOp::verify to prevent non-Builder-based Op construction
mechanisms from creating invalid IR.
PiperOrigin-RevId: 234798569
|
|
|
|
|
|
|
|
|
| |
- compute slices precisely where the destination iteration depends on multiple source
iterations (instead of over-approximating to the whole source loop extent)
- update unionBoundingBox to deal with input with non-matching symbols
- reenable disabled backend test case
PiperOrigin-RevId: 234714069
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generation pass to make it drop certain assumptions, complete TODOs.
- multiple fixes for getMemoryFootprintBytes
- pass loopDepth correctly from getMemoryFootprintBytes()
- use union while computing memory footprints
- bug fixes for addAffineForOpDomain
- take into account loop step
- add domains of other loop IVs in turn that might have been used in the bounds
- dma-generate: drop assumption of "non-unit stride loops being tile space loops
and skipping those and recursing to inner depths"; DMA generation is now purely
based on available fast mem capacity and memory footprint's calculated
- handle memory region compute failures/bailouts correctly from dma-generate
- loop tiling cleanup/NFC
- update some debug and error messages to use emitNote/emitError in
pipeline-data-transfer pass - NFC
PiperOrigin-RevId: 234245969
|
|
|
|
|
|
|
|
| |
FlatAffineConstraints::getLower/UpperBounds.
Update FlatAffineConstraints::getLower/UpperBounds to project to the identifier for which bounds are being computed. This change enables computing bounds on an identifier which were previously dependent on the bounds of another identifier.
PiperOrigin-RevId: 234017514
|
|
|
|
|
|
| |
some unnecessary factory methods on the Type class.
PiperOrigin-RevId: 233640730
|
|
|
|
|
|
|
|
| |
Associates opaque constants with a particular dialect. Adds general mechanism to register dialect-specific hooks defined in external components. Adds hooks to decode opaque tensor constant and extract an element of an opaque tensor constant.
This CL does not change the existing mechanism for registering constant folding hook yet. One thing at a time.
PiperOrigin-RevId: 233544757
|
|
|
|
|
|
| |
terminate a block and have block operands. This allows for any operation to hold block operands. It also introduces the notion that unregistered operations may terminate a block. As such, the 'isTerminator' api on Instruction has been split into 'isKnownTerminator' and 'isKnownNonTerminator'.
PiperOrigin-RevId: 233076831
|
|
|
|
| |
PiperOrigin-RevId: 232944889
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Aggregate types where at least one dimension is zero do not fully make sense as
they cannot contain any values (their total size is zero). However, TensorFlow
and XLA support tensors with zero sizes, so we must support those too. This is
relatively safe since, unlike vectors and memrefs, we don't have first-class
element accessors for MLIR tensors.
To support sparse element attributes of vector types that have no non-zero
elements, make sure that index and value element attributes have tensor type so
that we never need to create a zero vector type internally. Note that this is
already consistent with the inline documentation of the sparse elements
attribute. Users of the sparse elements attribute should not rely on the
storage schema anyway.
PiperOrigin-RevId: 232896707
|
|
|
|
| |
PiperOrigin-RevId: 232807986
|
|
|
|
|
|
| |
the AffineOps dialect with 'affine'.
PiperOrigin-RevId: 232728977
|
|
|
|
|
|
|
|
| |
Instead, we deduce the result type from the given attribute.
This is in preparation for generating constant ops with TableGen.
PiperOrigin-RevId: 232723467
|
|
|
|
|
|
| |
The is the second step to adding a namespace to the AffineOps dialect.
PiperOrigin-RevId: 232717775
|
|
|
|
|
|
|
|
|
| |
this feature during loop fusion cost computation, to compute what the write region of a fusion candidate loop nest slice would be (without having to materialize the slice or change the IR).
*) Adds parameter to public API of MemRefRegion::compute for passing in the slice loop bounds to compute the memref region of the loop nest slice.
*) Exposes public method MemRefRegion::getRegionSize for computing the size of the memref region in bytes.
PiperOrigin-RevId: 232706165
|
|
|
|
| |
PiperOrigin-RevId: 232704766
|
|
|
|
|
|
| |
AffineForOp.
PiperOrigin-RevId: 232610715
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AffineOps. This is important for allowing the affine dialect to define canonicalizations directly on the operations instead of relying on transformation passes, e.g. ComposeAffineMaps. A summary of the refactoring:
* AffineStructures has moved to IR.
* simplifyAffineExpr/simplifyAffineMap/getFlattenedAffineExpr have moved to IR.
* makeComposedAffineApply/fullyComposeAffineMapAndOperands have moved to AffineOps.
* ComposeAffineMaps is replaced by AffineApplyOp::canonicalize and deleted.
PiperOrigin-RevId: 232586468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Existing type syntax contains the following productions:
function-type ::= type-list-parens `->` type-list
type-list ::= type | type-list-parens
type ::= <..> | function-type
Due to these rules, when the parser sees `->` followed by `(`, it cannot
disambiguate if `(` starts a parenthesized list of function result types, or a
parenthesized list of operands of another function type, returned from the
current function. We would need an unknown amount of lookahead to try to find
the `->` at the right level of function nesting to differentiate between type
lists and singular function types.
Instead, require the result type of the function that is a function type itself
to be always parenthesized, at the syntax level. Update the spec and the
parser to correspond to the production rule names used in the spec (although it
would have worked without modifications). Fix the function type parsing bug in
the process, as it used to accept the non-parenthesized list of types for
arguments, disallowed by the spec.
PiperOrigin-RevId: 232528361
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In optional attribute dictionary used, among others, in the generic form of the
ops, attribute types for integers and floats are omitted. This could lead to
inconsistencies when round-tripping the IR, in particular the attributes are
created with incorrect types after parsing (integers default to i64, floats
default to f64). Provide API to emit a trailing type after the attribute for
integers and floats. Use it while printing the optional attribute dictionary.
Omitting types for i64 and f64 is a pragmatic decision that minimizes changes
in tests. We may want to reconsider in the future and always print types of
attributes in the generic form.
PiperOrigin-RevId: 232480116
|
|
|
|
|
|
| |
Function/Block/Instruction.
PiperOrigin-RevId: 232388113
|
|
|
|
|
|
| |
isValidDim/isValidSymbol methods from Value to the AffineOps dialect.
PiperOrigin-RevId: 232386632
|