[llvm][NFC] Fix typos: replace “avaliable” with “available” across various files (#114524)

This pull request corrects multiple occurrences of the typo "avaliable"
to "available" across the LLVM and

[llvm][NFC] Fix typos: replace “avaliable” with “available” across various files (#114524)

This pull request corrects multiple occurrences of the typo "avaliable"
to "available" across the LLVM and Clang codebase. These changes improve
the clarity and accuracy of comments and documentation. Specific
modifications are in the following files:

1. clang-tools-extra/clang-tidy/readability/FunctionCognitiveComplexityCheck.cpp:
Updated comments in readability checks for cognitive complexity.
2. llvm/include/llvm/ExecutionEngine/Orc/ExecutionUtils.h: Corrected
documentation for JITDylib responsibilities.
3. llvm/include/llvm/Target/TargetMacroFusion.td: Fixed descriptions for
FusionPredicate variables.
4. llvm/lib/CodeGen/SafeStack.cpp: Improved comments on DominatorTree
availability.
5. llvm/lib/Target/RISCV/RISCVSchedSiFive7.td: Enhanced resource usage
descriptions for vector units.
6. llvm/lib/Transforms/Scalar/LoopIdiomRecognize.cpp: Updated invariant
description in shift-detect idiom logic.
7. llvm/test/MC/ARM/mve-fp-registers.s: Amended ARM MVE register
availability notes.
8. mlir/lib/Bytecode/Reader/BytecodeReader.cpp: Adjusted forward
reference descriptions for bytecode reader operations.

These changes have no impact on code functionality, focusing solely on
documentation clarity.

Co-authored-by: wangqiang <wangqiang1@kylinos.cn>

show more ...

[Bytecode] Avoid repeated hash lookups (NFC) (#108320)

[mlir][BytecodeReader] Const qualify *SectionReader, NFC (#99376)

`StringSectionReader`, `ResourceSectionReader` and
`PropertiesSectionReader` are immutable after `initialize` so this PR
adds cons

[mlir][BytecodeReader] Const qualify *SectionReader, NFC (#99376)

`StringSectionReader`, `ResourceSectionReader` and
`PropertiesSectionReader` are immutable after `initialize` so this PR
adds const to their parsing functions and references in `AttrTypeReader`
and `DialectReader`.

show more ...

[mlir][bytecode] Fix external resource bytecode parsing (#97650)

The key was being dropped for external resources because they aren't
present in the dialect resource name mapper.

mlir/LogicalResult: move into llvm (#97309)

This patch is part of a project to move the Presburger library into
LLVM.

Fix bytecode roundtrip of unregistered ops (#82932)

When roundtripping to bytecode an unregistered operation name that does
not contain any '.' separator, the bytecode writer will emit an op
encod

Fix bytecode roundtrip of unregistered ops (#82932)

When roundtripping to bytecode an unregistered operation name that does
not contain any '.' separator, the bytecode writer will emit an op
encoding without a proper opName. In this case, the string just becomes
a possibly unknown dialect name. At parsing, this dialect name is
used as a proper operation name.

However, when the unregistered operation name coincidentally matches
that of a dialect, the parser would fail. That means we can't roundtrip
an unregistered op with a name that matches one of the registered
dialect names. For example,

```
"index"() : () -> ()
```

can be emitted but cannot be parsed, because its name is coincidentally
the same as that of the Index dialect. The patch removes such
inconsistency.

This patch specifically fixes the bytecode roundtrip of
`mlir/test/IR/parser.mlir`.

show more ...

Fix pipeline-invalid.mlir bytecode roundtrip test (#82366)

If an op was not contained in a region when was written to bytecode,
we don't have an initialized valueScope with forward references to
d

Fix pipeline-invalid.mlir bytecode roundtrip test (#82366)

If an op was not contained in a region when was written to bytecode,
we don't have an initialized valueScope with forward references to
define.

show more ...

[mlir] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,end

[mlir] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

[mlir] Fix bytecode reading of resource sections

This partially reverts #66380. The assertion that the underlying buffer
of an EncodingReader is aligned to any required alignments for resource
secti

[mlir] Fix bytecode reading of resource sections

This partially reverts #66380. The assertion that the underlying buffer
of an EncodingReader is aligned to any required alignments for resource
sections. Resources know their own alignment and pad their buffers
accordingly, but the bytecode reader doesn't know that ahead of time.
Consequently, it cannot give the resource EncodingReader a base buffer
aligned to the maximum required alignment.

A simple example from the test fails without this:

```mlir
module @TestDialectResources attributes {
bytecode.test = dense_resource<resource> : tensor<4xi32>
} {}
{-#
dialect_resources: {
builtin: {
resource: "0x2000000001000000020000000300000004000000",
resource_2: "0x2000000001000000020000000300000004000000"
}
}
```

show more ...

[mlir][bytecode] Check that bytecode source buffer is sufficiently aligned. (#66380)

Before this change, the `ByteCode` test failed on CentOS 7 with
devtoolset-9, because strings happen to be only

[mlir][bytecode] Check that bytecode source buffer is sufficiently aligned. (#66380)

Before this change, the `ByteCode` test failed on CentOS 7 with
devtoolset-9, because strings happen to be only 8 byte aligned. In
general though, strings have no alignment guarantee.

Increase resource alignment in test to 32 bytes.
Adjust test to sufficiently align buffer.
Add test to check error when buffer is insufficiently aligned.

show more ...

[mlir] Apply ClangTidy fix (NFC)

redundant get() call on smart pointer.

Expose callbacks for encoding of types/attributes

[mlir] Expose a mechanism to provide a callback for encoding types and attributes in MLIR bytecode.

Two callbacks are exposed, respectively, to the

Expose callbacks for encoding of types/attributes

[mlir] Expose a mechanism to provide a callback for encoding types and attributes in MLIR bytecode.

Two callbacks are exposed, respectively, to the BytecodeWriterConfig and to the ParserConfig. At bytecode parsing/printing, clients have the ability to specify a callback to be used to optionally read/write the encoding. On failure, fallback path will execute the default parsers and printers for the dialect.

Testing shows how to leverage this functionality to support back-deployment and backward-compatibility usecases when roundtripping to bytecode a client dialect with type/attributes dependencies on upstream.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D153383

show more ...

Revert "Expose callbacks for encoding of types/attributes"

This reverts commit b299ec16661f653df66cdaf161cdc5441bc9803c.

The authorship informations were incorrect.

Expose callbacks for encoding of types/attributes

[mlir] Expose a mechanism to provide a callback for encoding types and attributes in MLIR bytecode.

Two callbacks are exposed, respectively, to the

Expose callbacks for encoding of types/attributes

[mlir] Expose a mechanism to provide a callback for encoding types and attributes in MLIR bytecode.

Two callbacks are exposed, respectively, to the BytecodeWriterConfig and to the ParserConfig. At bytecode parsing/printing, clients have the ability to specify a callback to be used to optionally read/write the encoding. On failure, fallback path will execute the default parsers and printers for the dialect.

Testing shows how to leverage this functionality to support back-deployment and backward-compatibility usecases when roundtripping to bytecode a client dialect with type/attributes dependencies on upstream.

Reviewed By: rriddle

Differential Revision: https://reviews.llvm.org/D153383

show more ...

Update ODS variadic segments "magic" attributes to use native Properties

The operand_segment_sizes and result_segment_sizes Attributes are now inlined
in the operation as native propertie. We contin

Update ODS variadic segments "magic" attributes to use native Properties

The operand_segment_sizes and result_segment_sizes Attributes are now inlined
in the operation as native propertie. We continue to support building an
Attribute on the fly for `getAttr("operand_segment_sizes")` and setting the
property from an attribute with `setAttr("operand_segment_sizes", attr)`.

A new bytecode version is introduced to support backward compatibility and
backdeployments.

Differential Revision: https://reviews.llvm.org/D155919

show more ...

Revert "Update ODS variadic segments "magic" attributes to use native Properties"

This reverts commit 20b93abca6516bbb23689c3777536fea04e46e14.

One python test is broken, WIP.

Update ODS variadic segments "magic" attributes to use native Properties

The operand_segment_sizes and result_segment_sizes Attributes are now inlined
in the operation as native propertie. We contin

Update ODS variadic segments "magic" attributes to use native Properties

The operand_segment_sizes and result_segment_sizes Attributes are now inlined
in the operation as native propertie. We continue to support building an
Attribute on the fly for `getAttr("operand_segment_sizes")` and setting the
property from an attribute with `setAttr("operand_segment_sizes", attr)`.

A new bytecode version is introduced to support backward compatibility and
backdeployments.

Differential Revision: https://reviews.llvm.org/D155919

show more ...

[mlir][VectorType] Allow arbitrary dimensions to be scalable

At the moment, only the trailing dimensions in the vector type can be
scalable, i.e. this is supported:

vector<2x[4]xf32>

and this

[mlir][VectorType] Allow arbitrary dimensions to be scalable

At the moment, only the trailing dimensions in the vector type can be
scalable, i.e. this is supported:

vector<2x[4]xf32>

and this is not allowed:

vector<[2]x4xf32>

This patch extends the vector type so that arbitrary dimensions can be
scalable. To this end, an array of bool values is added to every vector
type to denote whether the corresponding dimensions are scalable or not.
For example, for this vector:

vector<[2]x[3]x4xf32>

the following array would be created:

{true, true, false}.

Additionally, the current syntax:

vector<[2x3]x4xf32>

is replaced with:

vector<[2]x[3]x4xf32>

This is primarily to simplify parsing (this way, the parser can easily
process one dimension at a time rather than e.g. tracking whether
"scalable block" has been entered/left).

NOTE: The `isScalableDim` parameter of `VectorType` (introduced in this
patch) makes `numScalableDims` redundant. For the time being,
`numScalableDims` is preserved to facilitate the transition between the
two parameters. `numScalableDims` will be removed in one of the
subsequent patches.

This change is a part of a larger effort to enable scalable
vectorisation in Linalg. See this RFC for more context:
* https://discourse.llvm.org/t/rfc-scalable-vectorisation-in-linalg/

Differential Revision: https://reviews.llvm.org/D153372

show more ...

[mlir][bytecode] Fix lazy loading of non-isolated regions

The bytecode reader currently assumes all regions can be lazy
loaded, which breaks reading any non-isolated region. This patch
fixes that by

[mlir][bytecode] Fix lazy loading of non-isolated regions

The bytecode reader currently assumes all regions can be lazy
loaded, which breaks reading any non-isolated region. This patch
fixes that by properly handling nested non-lazy regions, and only
considers isolated regions as lazy.

Differential Revision: https://reviews.llvm.org/D153795

show more ...

Fix bytecode reader/writer on big-endian platforms

This makes the bytecode reader/writer work on big-endian platforms.
The only problem was related to encoding of multi-byte integers,
where both rea

Fix bytecode reader/writer on big-endian platforms

This makes the bytecode reader/writer work on big-endian platforms.
The only problem was related to encoding of multi-byte integers,
where both reader and writer code make implicit assumptions about
endianness of the host platform.

This fixes the current test failures on s390x, and in addition allows
to remove the UNSUPPORTED markers from all other bytecode-related
test cases - they now also all pass on s390x.

Also adding a GFAIL_SKIP to the MultiModuleWithResource unit test,
as this still fails due to an unrelated endian bug regarding
decoding of external resources.

Differential Revision: https://reviews.llvm.org/D153567

Reviewed By: mehdi_amini, jpienaar, rriddle

show more ...

Use symbolic name for previous MLIR Bytecode versions

Reviewed By: jpienaar, burmako

Differential Revision: https://reviews.llvm.org/D151621

[mlir] Fix non-const lvalue reference to type 'uint64_t' cannot bind to type 'size_t' error (NFC)

/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:1007:39: error: non-const lval

[mlir] Fix non-const lvalue reference to type 'uint64_t' cannot bind to type 'size_t' error (NFC)

/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:1007:39: error: non-const lvalue reference to type 'uint64_t' (aka 'unsigned long long') cannot bind to a value of unrelated type 'size_t' (aka 'unsigned long')
if (failed(propReader.parseVarInt(count)))
^~~~~
/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:191:39: note: passing argument to parameter 'result' here
LogicalResult parseVarInt(uint64_t &result) {
^
/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:1020:44: error: non-const lvalue reference to type 'uint64_t' (aka 'unsigned long long') cannot bind to a value of unrelated type 'size_t' (aka 'unsigned long')
if (failed(offsetsReader.parseVarInt(dataSize)) ||
^~~~~~~~
/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:191:39: note: passing argument to parameter 'result' here
LogicalResult parseVarInt(uint64_t &result) {
^
2 errors generated.

show more ...

[MLIR] Add native Bytecode support for properties

This is adding a new interface (`BytecodeOpInterface`) to allow operations to
opt-in skipping conversion to attribute and serializing properties to

[MLIR] Add native Bytecode support for properties

This is adding a new interface (`BytecodeOpInterface`) to allow operations to
opt-in skipping conversion to attribute and serializing properties to native
bytecode.

The scheme relies on a new section where properties are stored in sequence

{ size, serialize_properties }, ...

The operations are storing the index of a properties, a table of offset is
built when loading the properties section the first time.

This is a re-commit of 837d1ce0dc which conflicted with another patch upgrading
the bytecode and the collision wasn't properly resolved before.

Differential Revision: https://reviews.llvm.org/D151065

show more ...

Revert "[MLIR] Add native Bytecode support for properties"

This reverts commit ca5a12fd69d4acf70c08f797cbffd714dd548348
and follow-up fixes:

df34c288c428eb4b867c8075def48b3d1727d60b
07dc906883af660

Revert "[MLIR] Add native Bytecode support for properties"

This reverts commit ca5a12fd69d4acf70c08f797cbffd714dd548348
and follow-up fixes:

df34c288c428eb4b867c8075def48b3d1727d60b
07dc906883af660780cf6d0cc1044f7e74dab83e
ab80ad0095083fda062c23ac90df84c40b4332c8
837d1ce0dc8eec5b17255291b3462e6296cb369b

The first commit was incomplete and broken, I'll prepare a new version
later, in the meantime pull this work out of tree.

show more ...

[mlir] Fix non-const lvalue reference to type 'uint64_t' cannot bind to type 'size_t' error (NFC)

/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:1007:39: error: non-const lval

[mlir] Fix non-const lvalue reference to type 'uint64_t' cannot bind to type 'size_t' error (NFC)

/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:1007:39: error: non-const lvalue reference to type 'uint64_t' (aka 'unsigned long long') cannot bind to a value of unrelated type 'size_t' (aka 'unsigned long')
if (failed(propReader.parseVarInt(count)))
^~~~~
/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:191:39: note: passing argument to parameter 'result' here
LogicalResult parseVarInt(uint64_t &result) {
^
/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:1033:41: error: non-const lvalue reference to type 'uint64_t' (aka 'unsigned long long') cannot bind to a value of unrelated type 'size_t' (aka 'unsigned long')
if (failed(dialectReader.readVarInt(propertiesIdx)))
^~~~~~~~~~~~~
/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:926:38: note: passing argument to parameter 'result' here
LogicalResult readVarInt(uint64_t &result) override {
^
2 errors generated.

/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:1033:41: error: non-const lvalue reference to type 'uint64_t' (aka 'unsigned long long') cannot bind to a value of unrelated type 'size_t' (aka 'unsigned long')
if (failed(dialectReader.readVarInt(propertiesIdx)))
^~~~~~~~~~~~~
/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:926:38: note: passing argument to parameter 'result' here
LogicalResult readVarInt(uint64_t &result) override {
^
1 error generated.

show more ...