Clang update llvm 21.x #12
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ermilindwalekar
force-pushed
the
clang_update_llvm_21.x
branch
from
d46300b to
36111b4
Compare
Based on the following discussion: https://llvm.discourse.group/t/declarative-assembly-format-requirement-for-type-presence/4399 Relax checks in `OperationParser` - it allows to skip value type specification, if the value was already defined in the same block. Differential Revision: https://reviews.llvm.org/D111650
add support for SymbolContainer trait in MLIR infrastructure
…lvm#37) * added integral type check * changed to f8e_m_ format, removed isF8 helper method, formatting * added negative tests, removed duplicate test * Added endline in parse-uniform-invalid.mlir * changed to f8E5M2/f8E4M3FN format, enabled default type parsing * updated parse-any-invalid error message checks
* Fix <anonymous> declared here * Fix Ubuntu24 (llvm#33)
* Expanding Quant dialect with Quantile Quantized type * Adding quantile mlir tests * Adding check on quantiles array size and updated mlir tests
* relax negative scale conditions * adapt tests now handling negative scales
* Adding missing check in QuantileQuantizedPerAxisType::verify * Adding minor test for illegal quantile array size for per axis type
This reverses partially changed in commit 2c1ae80
…bolTable (llvm#80590)" This reverts commit 7d055af.
…ARNINGS is ON (llvm#99) Signed-off-by: Zhu, Shaojie <[email protected]>
…and-line parser reset When LLVM TableGen flags are globally appended, mlir-src-sharder fails with an unknown argument error because its command-line parser is reset during execution and does not retain the inherited flags.
After the original API change to DefaultTimingManager::setOutput() (see 362aa43), users are forced to provide their own implementation of OutputStrategy. However, default MLIR implementations are usually sufficient. Expose Text and Json strategies via factory-like method to avoid the problem in downstream projects.
…vm#159766) Support custom types (3/N): allow custom tensor and buffer types in function signatures and at call-sites. This is one of the major building blocks to move in the direction of module-level one-shot-bufferization support. To achieve this, `BufferizationOptions::FunctionArgTypeConverterFn` callback is converted to work with tensor-like and buffer-like types, instead of the builtin counterparts. The default behavior for builtins remains unchanged, while custom types by default go through `TensorLikeType::getBufferType()` which is a general conversion interface.
…vm#170) Duplicate of PR merged on npu/release/19.x llvm#151 Cherry-pick from upstream llvm: llvm#147721; adding std::move to getChecked method.
…#167705) Generally, to_tensor and to_buffer already perform sufficient verification. However, there are some unnecessarily strict constraints: * builtin tensor requires its buffer counterpart to always be memref * to_buffer on ranked tensor requires to always return memref These checks are assertions (i.e. preconditions), however, they actually prevent an apparently useful bufferization where builtin tensors could become custom buffers. Lift these assertions, maintaining the verification procedure unchanged, to allow builtin -> custom bufferizations at operation boundary level.
…ted code (llvm#168536) (llvm#181) ODS generate code can be included and used outside of the `mlir` namespace and so references to symbols in the mlir namespace must be fully qualified.
The recent changes in the MLIR TableGen interface for generated
OpTy::build functions involves a new OpTy::create function that is
generated passing arguments without forwarding. This is problematic with
arguments that are move only such as `std::unique_ptr`. My particular
use case involves `std::unique_ptr<mlir::Region>` which is desirable as
the `mlir::OperationState` object accepts calls to
`addRegion(std::unique_ptr<mlir::Region>`.
In Discord, the use of `extraClassDeclarations` was suggested which I
may go with regardless since I still have to define the builder function
anyways, but perhaps you would consider this trivial change as it
supports a broader class of argument types for this approach.
Consider the declaration in TableGen:
```
let builders = [
OpBuilder<(ins "::mlir::Value":$cdr,
"::mlir::ValueRange":$packs,
"std::unique_ptr<::mlir::Region>":$body)>
];
```
Which currently generates:
```cpp
ExpandPacksOp ExpandPacksOp::create(::mlir::OpBuilder &builder, ::mlir::Location location, ::mlir::Value cdr, ::mlir::ValueRange packs, std::unique_ptr<::mlir::Region> body) {
::mlir::OperationState __state__(location, getOperationName());
build(builder, __state__, std::forward<decltype(cdr)>(cdr), std::forward<decltype(packs)>(packs), std::forward<decltype(body)>(body));
auto __res__ = ::llvm::dyn_cast<ExpandPacksOp>(builder.create(__state__));
assert(__res__ && "builder didn't return the right type");
return __res__;
}
```
With this change it will generate:
```cpp
ExpandPacksOp ExpandPacksOp::create(::mlir::OpBuilder &builder, ::mlir::Location location, ::mlir::Value cdr, ::mlir::ValueRange packs, std::unique_ptr<::mlir::Region>&&body) {
::mlir::OperationState __state__(location, getOperationName());
build(builder, __state__, static_cast<decltype(cdr)>(cdr), std::forward<decltype(packs)>(packs), std::forward<decltype(body)>(body));
auto __res__ = ::llvm::dyn_cast<ExpandPacksOp>(builder.create(__state__));
assert(__res__ && "builder didn't return the right type");
return __res__;
}
```
Another option could be to make this function a template but then it
would not be hidden in the generated translation unit. I don't know if
that was the original intent. Thank you for your consideration.
…eConversionsAndLegality (llvm#160344) In a downstream project, there is a need for a type conversion pattern for scf.index_switch operation. A test is added into `mlir/test/Dialect/SparseTensor/scf_1_N_conversion.mlir` (not sure this functionality is really required for sparse tensors, but the test showcase that the new conversion pattern is functional)
ermilindwalekar
force-pushed
the
clang_update_llvm_21.x
branch
from
36111b4 to
8ee6ab0
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
17 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
JIRA ticket
Related PR in NPU Compiler and/or OpenVINO repository with sub-module update
Other related tickets