Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5 |
|
#
01e75646 |
| 23-Nov-2024 |
Jacques Pienaar <jpienaar@google.com> |
[mlir] Add FileRange location type. (#80213)
This location type represents a contiguous range inside a file. It is
effectively a pair of FileLineCols. Add new type and make FileLineCol a
view for
[mlir] Add FileRange location type. (#80213)
This location type represents a contiguous range inside a file. It is
effectively a pair of FileLineCols. Add new type and make FileLineCol a
view for case where it matches existing previous one.
The location includes filename and optional start line & col, and end
line & col. Considered common cases are file:line, file:line:col,
file:line:start_col to file:line:end_col and general range within same
file. In memory its encoded as trailing objects. This keeps the memory
requirement the same as FileLineColLoc today (makes the rather common
File:Line cheaper) at the expense of extra work at decoding time. Kept the unsigned
type.
There was the option to always have file range be castable to
FileLineColLoc. This cast would just drop other fields. That may result
in some simpler staging. TBD.
This is a rather minimal change, it does not yet add bindings (C or
Python), lowering to LLVM debug locations etc. that supports end line:cols.
---------
Co-authored-by: River Riddle <riddleriver@gmail.com>
show more ...
|
Revision tags: llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4 |
|
#
b39958c2 |
| 20-Oct-2023 |
Mehdi Amini <joker.eph@gmail.com> |
Apply clang-tidy fixes for llvm-else-after-return in BuiltinDialectBytecode.cpp (NFC)
|
Revision tags: llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
728a8d5a |
| 11-Jul-2023 |
Tobias Gysi <tobias.gysi@nextsilicon.com> |
[mlir] Add a builtin distinct attribute
A distinct attribute associates a referenced attribute with a unique identifier. Every call to its create function allocates a new distinct attribute instance
[mlir] Add a builtin distinct attribute
A distinct attribute associates a referenced attribute with a unique identifier. Every call to its create function allocates a new distinct attribute instance. The address of the attribute instance temporarily serves as its unique identifier. Similar to the names of SSA values, the final unique identifiers are generated during pretty printing.
Examples: #distinct = distinct[0]<42.0 : f32> #distinct1 = distinct[1]<42.0 : f32> #distinct2 = distinct[2]<array<i32: 10, 42>>
This mechanism is meant to generate attributes with a unique identifier, which can be used to mark groups of operations that share a common properties such as if they are aliasing.
The design of the distinct attribute ensures minimal memory footprint per distinct attribute since it only contains a reference to another attribute. All distinct attributes are stored outside of the storage uniquer in a thread local store that is part of the context. It uses one bump pointer allocator per thread to ensure distinct attributes can be created in-parallel.
Reviewed By: rriddle, Dinistro, zero9178
Differential Revision: https://reviews.llvm.org/D153360
show more ...
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5 |
|
#
5f649130 |
| 24-May-2023 |
Mehdi Amini <joker.eph@gmail.com> |
Fix MLIR bytecode reading of i0 IntegerAttr
The move of the bytecode serialization to be tablegen driven in https://reviews.llvm.org/D144820 added a new condition in the reading path that forbid 0-s
Fix MLIR bytecode reading of i0 IntegerAttr
The move of the bytecode serialization to be tablegen driven in https://reviews.llvm.org/D144820 added a new condition in the reading path that forbid 0-sized integer, even though we still produce them.
Fix #62920
Differential Revision: https://reviews.llvm.org/D151372
show more ...
|
Revision tags: llvmorg-16.0.4 |
|
#
c1fa60b4 |
| 11-May-2023 |
Tres Popp <tpopp@google.com> |
[mlir] Update method cast calls to function calls
The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in a
[mlir] Update method cast calls to function calls
The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in addition to defining methods with the same name. This change begins the migration of uses of the method to the corresponding function call as has been decided as more consistent.
Note that there still exist classes that only define methods directly, such as AffineExpr, and this does not include work currently to support a functional cast/isa call.
Context:
* https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…" * Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443
Implementation: This follows a previous patch that updated calls `op.cast<T>()-> cast<T>(op)`. However some cases could not handle an unprefixed `cast` call due to occurrences of variables named cast, or occurring inside of class definitions which would resolve to the method. All C++ files that did not work automatically with `cast<T>()` are updated here to `llvm::cast` and similar with the intention that they can be easily updated after the methods are removed through a find-replace.
See https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check for the clang-tidy check that is used and then update printed occurrences of the function to include `llvm::` before.
One can then run the following: ``` ninja -C $BUILD_DIR clang-tidy
run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -export-fixes /tmp/cast/casts.yaml mlir/*\ -header-filter=mlir/ -fix
rm -rf $BUILD_DIR/tools/mlir/**/*.inc ```
Differential Revision: https://reviews.llvm.org/D150348
show more ...
|
Revision tags: llvmorg-16.0.3 |
|
#
09115580 |
| 24-Apr-2023 |
Jacques Pienaar <jpienaar@google.com> |
[mlir] Dialect type/attr bytecode read/write generator.
Tool to help generate dialect bytecode Attribute & Type reader/writing. Show usage by flipping builtin dialect.
It helps reduce boilerplate w
[mlir] Dialect type/attr bytecode read/write generator.
Tool to help generate dialect bytecode Attribute & Type reader/writing. Show usage by flipping builtin dialect.
It helps reduce boilerplate when writing dialect bytecode attribute and type readers/writers. It is not an attempt at a generic spec mechanism but rather practically focussing on boilerplate reduction while also considering that it need not be the only in memory format and make it relatively easy to change.
There should be some cleanup in follow up as we expand to more dialects.
Differential Revision: https://reviews.llvm.org/D144820
show more ...
|
Revision tags: llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5 |
|
#
c48e0cf0 |
| 08-Nov-2022 |
Jeff Niu <jeff@modular.com> |
[mlir] Remove TypedAttr and ElementsAttr from DenseArrayAttr
This patch removes the implementation of TypedAttr and ElementsAttr from DenseArrayAttr and, in doing so, removes the need store a shaped
[mlir] Remove TypedAttr and ElementsAttr from DenseArrayAttr
This patch removes the implementation of TypedAttr and ElementsAttr from DenseArrayAttr and, in doing so, removes the need store a shaped type. The attribute now stores a size (number of elements), an MLIR type as a discriminator, and a raw byte array.
The intent of DenseArrayAttr was not to be a drop-in replacement for DenseElementsAttr. It was meant to be a simple container of integers or floats that map to C++ types. The ElementsAttr implementation on DenseArrayAttr had many holes in it, and fixing those holes would require evolving DenseArrayAttr in a way that is incompatible with its original purpose.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D137606
show more ...
|
Revision tags: llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1 |
|
#
5fb1bbe6 |
| 13-Sep-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir] Add bytecode encodings for the builtin ElementsAttr attributes
This adds bytecode support for DenseArrayAttr, DenseIntOrFpElementsAttr, DenseStringElementsAttr, and SparseElementsAttr.
Diffe
[mlir] Add bytecode encodings for the builtin ElementsAttr attributes
This adds bytecode support for DenseArrayAttr, DenseIntOrFpElementsAttr, DenseStringElementsAttr, and SparseElementsAttr.
Differential Revision: https://reviews.llvm.org/D133744
show more ...
|
#
6ab2bcff |
| 07-Sep-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir:Bytecode] Add support for encoding resources
Resources are encoded in two separate sections similarly to attributes/types, one for the actual data and one for the data offsets. Unlike other se
[mlir:Bytecode] Add support for encoding resources
Resources are encoded in two separate sections similarly to attributes/types, one for the actual data and one for the data offsets. Unlike other sections, the resource sections are optional given that in many cases they won't be present. For testing, bytecode serialization is added for DenseResourceElementsAttr.
Differential Revision: https://reviews.llvm.org/D132729
show more ...
|
Revision tags: llvmorg-15.0.0, llvmorg-15.0.0-rc3 |
|
#
85744059 |
| 24-Aug-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir] Add bytecode encoding for the remaining builtin types
After this commit we will have an efficient bytecode representation for all of the builtin types.
Differential Revision: https://reviews
[mlir] Add bytecode encoding for the remaining builtin types
After this commit we will have an efficient bytecode representation for all of the builtin types.
Differential Revision: https://reviews.llvm.org/D132604
show more ...
|
#
89c975a6 |
| 24-Aug-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir][NFC] Cleanup builtin dialect bytecode encoding
Group the readers and writers for individual attributes/types together, which makes the encoding more readable.
Differential Revision: https://
[mlir][NFC] Cleanup builtin dialect bytecode encoding
Group the readers and writers for individual attributes/types together, which makes the encoding more readable.
Differential Revision: https://reviews.llvm.org/D132583
show more ...
|
#
772994f1 |
| 24-Aug-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir:Bytecode] Add encoding support for builtin location attributes
This provides a significantly more efficient encoding for locations.
Differential Revision: https://reviews.llvm.org/D132540
|
#
2f90764c |
| 24-Aug-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir:Bytecode] Add encoding support for a majority of the builtin attributes
This adds support for the non-location, non-elements, non-affine builtin attributes.
Differential Revision: https://rev
[mlir:Bytecode] Add encoding support for a majority of the builtin attributes
This adds support for the non-location, non-elements, non-affine builtin attributes.
Differential Revision: https://reviews.llvm.org/D132539
show more ...
|
#
02c2ecb9 |
| 23-Aug-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir:Bytecode] Add initial support for dialect defined attribute/type encodings
Dialects can opt-in to providing custom encodings by implementing the `BytecodeDialectInterface`. This interface prov
[mlir:Bytecode] Add initial support for dialect defined attribute/type encodings
Dialects can opt-in to providing custom encodings by implementing the `BytecodeDialectInterface`. This interface provides hooks, namely `readAttribute`/`readType` and `writeAttribute`/`writeType`, that will be used by the bytecode reader and writer. These hooks are provided a reader and writer implementation that can be used to encode various constructs in the underlying bytecode format. A unique feature of this interface is that dialects may choose to only encode a subset of their attributes and types in a custom bytecode format, which can simplify adding new or experimental components that aren't fully baked.
Differential Revision: https://reviews.llvm.org/D132498
show more ...
|