History log of /llvm-project/mlir/lib/IR/BuiltinDialectBytecode.cpp (Results 1 – 14 of 14)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...