[mlir][NFC] Update textual references of `func` to `func.func` in Bufferization/Complex/EmitC/CF/Func/GPU testsThe special case parsing of `func` operations is being removed.
[mlir][RFC] Add scalable dimensions to VectorTypeWith VectorType supporting scalable dimensions, we don't need many ofthe operations currently present in ArmSVE, like mask generation andbasic ari
[mlir][RFC] Add scalable dimensions to VectorTypeWith VectorType supporting scalable dimensions, we don't need many ofthe operations currently present in ArmSVE, like mask generation andbasic arithmetic instructions. Therefore, this patch also getsrid of those.Having built-in scalable vector support also simplifies the lowering ofscalable vector dialects down to LLVMIR.Scalable dimensions are indicated with the scalable dimensionsbetween square brackets: vector<[4]xf32>Is a scalable vector of 4 single precission floating point elements.More generally, a VectorType can have a set of fixed-length dimensionsfollowed by a set of scalable dimensions: vector<2x[4x4]xf32>Is a vector with 2 scalable 4x4 vectors of single precission floatingpoint elements.The scale of the scalable dimensions can be obtained with the Vectoroperation: %vs = vector.vscaleThis change is being discussed in the discourse RFC:https://llvm.discourse.group/t/rfc-add-built-in-support-for-scalable-vector-types/4484Differential Revision: https://reviews.llvm.org/D111819
show more ...
Add a new interface allowing to set a default dialect to be used for printing/parsing regionsCurrently the builtin dialect is the default namespace used for parsingand printing. As such module and
Add a new interface allowing to set a default dialect to be used for printing/parsing regionsCurrently the builtin dialect is the default namespace used for parsingand printing. As such module and func don't need to be prefixed.In the case of some dialects that defines new regions for their ownpurpose (like SpirV modules for example), it can be beneficial tochange the default dialect in order to improve readability.Differential Revision: https://reviews.llvm.org/D107236
[mlir] Set the namespace of the BuiltinDialect to 'builtin'Historically the builtin dialect has had an empty namespace. This has unfortunately created a very awkward situation, where many utilities
[mlir] Set the namespace of the BuiltinDialect to 'builtin'Historically the builtin dialect has had an empty namespace. This has unfortunately created a very awkward situation, where many utilities either have to special case the empty namespace, or just don't work at all right now. This revision adds a namespace to the builtin dialect, and starts to cleanup some of the utilities to no longer handle empty namespaces. For now, the assembly form of builtin operations does not require the `builtin.` prefix. (This should likely be re-evaluated though)Differential Revision: https://reviews.llvm.org/D105149
[mlir] Add a new builtin `unrealized_conversion_cast` operationAn `unrealized_conversion_cast` operation represents an unrealized conversionfrom one set of types to another, that is used to enable
[mlir] Add a new builtin `unrealized_conversion_cast` operationAn `unrealized_conversion_cast` operation represents an unrealized conversionfrom one set of types to another, that is used to enable the inter-mixing ofdifferent type systems. This operation should not be attributed any specialrepresentational or execution semantics, and is generally only intended to beused to satisfy the temporary intermixing of type systems during the conversionof one type system to another.This operation was discussed in the following RFC(and ODM):https://llvm.discourse.group/t/open-meeting-1-14-dialect-conversion-and-type-conversion-the-question-of-cast-operations/Differential Revision: https://reviews.llvm.org/D94832