Revision tags: llvmorg-11.0.0-rc2 |
|
#
b98e25b6 |
| 19-Aug-2020 |
Benjamin Kramer <benny.kra@googlemail.com> |
Make helpers static. NFC.
|
#
168213f9 |
| 17-Aug-2020 |
Alex Zinenko <zinenko@google.com> |
[mlir] Move data layout from LLVMDialect to module Op attributes
Legacy implementation of the LLVM dialect in MLIR contained an instance of llvm::Module as it was required to parse LLVM IR types. Th
[mlir] Move data layout from LLVMDialect to module Op attributes
Legacy implementation of the LLVM dialect in MLIR contained an instance of llvm::Module as it was required to parse LLVM IR types. The access to the data layout of this module was exposed to the users for convenience, but in practice this layout has always been the default one obtained by parsing an empty layout description string. Current implementation of the dialect no longer relies on wrapping LLVM IR types, but it kept an instance of DataLayout for compatibility. This effectively forces a single data layout to be used across all modules in a given MLIR context, which is not desirable. Remove DataLayout from the LLVM dialect and attach it as a module attribute instead. Since MLIR does not yet have support for data layouts, use the LLVM DataLayout in string form with verification inside MLIR. Introduce the layout when converting a module to the LLVM dialect and keep the default "" description for compatibility.
This approach should be replaced with a proper MLIR-based data layout when it becomes available, but provides an immediate solution to compiling modules with different layouts, e.g. for GPUs.
This removes the need for LLVMDialectImpl, which is also removed.
Depends On D85650
Reviewed By: aartbik
Differential Revision: https://reviews.llvm.org/D85652
show more ...
|
#
0de60b55 |
| 10-Aug-2020 |
Thomas Raoux <thomasraoux@google.com> |
[mlir] Fix mlir build break due to warning when NDEBUG is not set
|
#
68330ee0 |
| 10-Aug-2020 |
Thomas Raoux <thomasraoux@google.com> |
[mlir][vector] Relax transfer_read/transfer_write restriction on memref operand
Relax the verifier for transfer_read/transfer_write operation so that it can take a memref with a different element ty
[mlir][vector] Relax transfer_read/transfer_write restriction on memref operand
Relax the verifier for transfer_read/transfer_write operation so that it can take a memref with a different element type than the vector being read/written.
This is based on the discourse discussion: https://llvm.discourse.group/t/memref-cast/1514
Differential Revision: https://reviews.llvm.org/D85244
show more ...
|
#
c3c95b9c |
| 06-Aug-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] Improve lowering of extract_strided_slice (and friends like shape_cast)
Using a shuffle for the last recursive step in progressive lowering not only results in much more compact I
[mlir] [VectorOps] Improve lowering of extract_strided_slice (and friends like shape_cast)
Using a shuffle for the last recursive step in progressive lowering not only results in much more compact IR, but also more efficient code (since the backend is no longer confused on subvector aliasing for longer vectors).
E.g. the following
%f = vector.shape_cast %v0: vector<1024xf32> to vector<32x32xf32>
yields much better x86-64 code that runs 3x faster than the original.
Reviewed By: bkramer, nicolasvasilache
Differential Revision: https://reviews.llvm.org/D85482
show more ...
|
#
87a89e0f |
| 06-Aug-2020 |
Alex Zinenko <zinenko@google.com> |
[mlir] Remove llvm::LLVMContext and llvm::Module from mlir::LLVMDialectImpl
Original modeling of LLVM IR types in the MLIR LLVM dialect had been wrapping LLVM IR types and therefore required the LLV
[mlir] Remove llvm::LLVMContext and llvm::Module from mlir::LLVMDialectImpl
Original modeling of LLVM IR types in the MLIR LLVM dialect had been wrapping LLVM IR types and therefore required the LLVMContext in which they were created to outlive them, which was solved by placing the LLVMContext inside the dialect and thus having the lifetime of MLIRContext. This has led to numerous issues caused by the lack of thread-safety of LLVMContext and the need to re-create LLVM IR modules, obtained by translating from MLIR, in different LLVM contexts to enable parallel compilation. Similarly, llvm::Module had been introduced to keep track of identified structure types that could not be modeled properly.
A recent series of commits changed the modeling of LLVM IR types in the MLIR LLVM dialect so that it no longer wraps LLVM IR types and has no dependence on LLVMContext and changed the ownership model of the translated LLVM IR modules. Remove LLVMContext and LLVM modules from the implementation of MLIR LLVM dialect and clean up the remaining uses.
The only part of LLVM IR that remains necessary for the LLVM dialect is the data layout. It should be moved from the dialect level to the module level and replaced with an MLIR-based representation to remove the dependency of the LLVMDialect on LLVM IR library.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D85445
show more ...
|
#
5446ec85 |
| 05-Aug-2020 |
Alex Zinenko <zinenko@google.com> |
[mlir] take MLIRContext instead of LLVMDialect in getters of LLVMType's
Historical modeling of the LLVM dialect types had been wrapping LLVM IR types and therefore needed access to the instance of L
[mlir] take MLIRContext instead of LLVMDialect in getters of LLVMType's
Historical modeling of the LLVM dialect types had been wrapping LLVM IR types and therefore needed access to the instance of LLVMContext stored in the LLVMDialect. The new modeling does not rely on that and only needs the MLIRContext that is used for uniquing, similarly to other MLIR types. Change LLVMType::get<Kind>Ty functions to take `MLIRContext *` instead of `LLVMDialect *` as first argument. This brings the code base closer to completely removing the dependence on LLVMContext from the LLVMDialect, together with additional support for thread-safety of its use.
Depends On D85371
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D85372
show more ...
|
#
d3a98076 |
| 05-Aug-2020 |
Alex Zinenko <zinenko@google.com> |
[mlir] Remove most uses of LLVMDialect::getModule
This prepares for the removal of llvm::Module and LLVMContext from the mlir::LLVMDialect.
Reviewed By: rriddle
Differential Revision: https://revi
[mlir] Remove most uses of LLVMDialect::getModule
This prepares for the removal of llvm::Module and LLVMContext from the mlir::LLVMDialect.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D85371
show more ...
|
#
39379916 |
| 05-Aug-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] Add masked load/store operations to Vector dialect
The intrinsics were already supported and vector.transfer_read/write lowered direclty into these operations. By providing them a
[mlir] [VectorOps] Add masked load/store operations to Vector dialect
The intrinsics were already supported and vector.transfer_read/write lowered direclty into these operations. By providing them as individual ops, however, clients can used them directly, and it opens up progressively lowering transfer operations at higher levels (rather than direct lowering to LLVM IR as done now).
Reviewed By: bkramer
Differential Revision: https://reviews.llvm.org/D85357
show more ...
|
#
b2ab375d |
| 05-Aug-2020 |
Alex Zinenko <zinenko@google.com> |
[mlir] use the new stateful LLVM type translator by default
Previous type model in the LLVM dialect did not support identified structure types properly and therefore could use stateless translations
[mlir] use the new stateful LLVM type translator by default
Previous type model in the LLVM dialect did not support identified structure types properly and therefore could use stateless translations implemented as free functions. The new model supports identified structs and must keep track of the identified structure types present in the target context (LLVMContext or MLIRContext) to avoid creating duplicate structs due to LLVM's type auto-renaming. Expose the stateful type translation classes and use them during translation, storing the state as part of ModuleTranslation.
Drop the test type translation mechanism that is no longer necessary and update the tests to exercise type translation as part of the main translation flow.
Update the code in vector-to-LLVM dialect conversion that relied on stateless translation to use the new class in a stateless manner.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D85297
show more ...
|
#
e8dcf5f8 |
| 31-Jul-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] Add expand/compress operations to Vector dialect
Introduces the expand and compress operations to the Vector dialect (important memory operations for sparse computations), togethe
[mlir] [VectorOps] Add expand/compress operations to Vector dialect
Introduces the expand and compress operations to the Vector dialect (important memory operations for sparse computations), together with a first reference implementation that lowers to the LLVM IR dialect to enable running on CPU (and other targets that support the corresponding LLVM IR intrinsics).
Reviewed By: reidtatge
Differential Revision: https://reviews.llvm.org/D84888
show more ...
|
#
ec1f4e7c |
| 04-Aug-2020 |
Alex Zinenko <zinenko@google.com> |
[mlir] switch the modeling of LLVM types to use the new mechanism
A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wr
[mlir] switch the modeling of LLVM types to use the new mechanism
A new first-party modeling for LLVM IR types in the LLVM dialect has been developed in parallel to the existing modeling based on wrapping LLVM `Type *` instances. It resolves the long-standing problem of modeling identified structure types, including recursive structures, and enables future removal of LLVMContext and related locking mechanisms from LLVMDialect.
This commit only switches the modeling by (a) renaming LLVMTypeNew to LLVMType, (b) removing the old implementaiton of LLVMType, and (c) updating the tests. It is intentionally minimal. Separate commits will remove the infrastructure built for the transition and update API uses where appropriate.
Depends On D85020
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D85021
show more ...
|
Revision tags: llvmorg-11.0.0-rc1 |
|
#
aec38c61 |
| 23-Jul-2020 |
Alex Zinenko <zinenko@google.com> |
[mlir] LLVMType: make getUnderlyingType private
The current modeling of LLVM IR types in MLIR is based on the LLVMType class that wraps a raw `llvm::Type *` and delegates uniquing, printing and pars
[mlir] LLVMType: make getUnderlyingType private
The current modeling of LLVM IR types in MLIR is based on the LLVMType class that wraps a raw `llvm::Type *` and delegates uniquing, printing and parsing to LLVM itself. This is model makes thread-safe type manipulation hard and is being progressively replaced with a cleaner MLIR model that replicates the type system. In the new model, LLVMType will no longer have an underlying LLVM IR type. Restrict access to this type in the current model in preparation for the change.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D84389
show more ...
|
#
1485fd29 |
| 23-Jul-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] Improve scatter/gather CPU performance
Replaced the linearized address with the proper LLVM way of defining vector of base + indices in SIMD style. This yields much better code. S
[mlir] [VectorOps] Improve scatter/gather CPU performance
Replaced the linearized address with the proper LLVM way of defining vector of base + indices in SIMD style. This yields much better code. Some prototype results with microbencmarking sparse matrix x vector with 50% sparsity (about 2-3x faster):
LINEARIZED IMPROVED GFLOPS sdot saxpy sdot saxpy 16x16 1.6 1.4 4.4 2.1 32x32 1.7 1.6 5.8 5.9 64x64 1.7 1.7 6.4 6.4 128x128 1.7 1.7 5.9 5.9 256x256 1.6 1.6 6.1 6.0 512x512 1.4 1.4 4.9 4.7
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D84368
show more ...
|
#
19dbb230 |
| 21-Jul-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] Add scatter/gather operations to Vector dialect
Introduces the scatter/gather operations to the Vector dialect (important memory operations for sparse computations), together with
[mlir] [VectorOps] Add scatter/gather operations to Vector dialect
Introduces the scatter/gather operations to the Vector dialect (important memory operations for sparse computations), together with a first reference implementation that lowers to the LLVM IR dialect to enable running on CPU (and other targets that support the corresponding LLVM IR intrinsics).
The operations can be used directly where applicable, or can be used during progressively lowering to bring other memory operations closer to hardware ISA support for a gather/scatter. The semantics of the operation closely correspond to those of the corresponding llvm intrinsics.
Note that the operation allows for a dynamic index vector (which is important for sparse computations). However, this first reference lowering implementation "serializes" the address computation when base + index_vector is converted to a vector of pointers. Exploring how to use SIMD properly during these step is TBD. More general memrefs and idiomatic versions of striding are also TBD.
Reviewed By: arpith-jacob
Differential Revision: https://reviews.llvm.org/D84039
show more ...
|
Revision tags: llvmorg-12-init |
|
#
affbc0cd |
| 13-Jul-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir] Add alignment attribute to LLVM memory ops and use in vector.transfer
Summary: The native alignment may generally not be used when lowering a vector.transfer to the underlying load/store oper
[mlir] Add alignment attribute to LLVM memory ops and use in vector.transfer
Summary: The native alignment may generally not be used when lowering a vector.transfer to the underlying load/store operation. This revision fixes the unmasked load/store alignment to match that of the masked path.
Differential Revision: https://reviews.llvm.org/D83684
show more ...
|
#
3bffe602 |
| 13-Jul-2020 |
Benjamin Kramer <benny.kra@googlemail.com> |
[mlir][VectorOps] Lower vector.fma to llvm.fmuladd instead of llvm.fma
Summary: These are semantically equivalent, but fmuladd allows decaying the op into fmul+fadd if there is no fma instruction av
[mlir][VectorOps] Lower vector.fma to llvm.fmuladd instead of llvm.fma
Summary: These are semantically equivalent, but fmuladd allows decaying the op into fmul+fadd if there is no fma instruction available. llvm.fma lowers to scalar calls to libm fmaf, which is a lot slower.
Reviewers: nicolasvasilache, aartbik, ftynse
Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, Kayjukh, jurahul, msifontes
Tags: #mlir
Differential Revision: https://reviews.llvm.org/D83666
show more ...
|
#
1bfdf7c7 |
| 08-Jul-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] Expose lowering pass options programmatically
The ConvertVectorToLLVM pass defines options that can be passed on the command line (currently only reassociation of FP reductions th
[mlir] [VectorOps] Expose lowering pass options programmatically
The ConvertVectorToLLVM pass defines options that can be passed on the command line (currently only reassociation of FP reductions through -convert-vector-to-llvm='reassociate-fp-reductions). This CL enables setting these options programmatically (forward looking to more options than just reassociation, as well as setting the values from code rather than command line).
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D83420
show more ...
|
Revision tags: llvmorg-10.0.1, llvmorg-10.0.1-rc4 |
|
#
9db53a18 |
| 07-Jul-2020 |
River Riddle <riddleriver@gmail.com> |
[mlir][NFC] Remove usernames and google bug numbers from TODO comments.
These were largely leftover from when MLIR was a google project, and don't really follow LLVM guidelines.
|
Revision tags: llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
#
ceb1b327 |
| 26-Jun-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] Add the ability to mark FP reductions with "reassociate" attribute
Rationale: In general, passing "fastmath" from MLIR to LLVM backend is not supported, and even just providing su
[mlir] [VectorOps] Add the ability to mark FP reductions with "reassociate" attribute
Rationale: In general, passing "fastmath" from MLIR to LLVM backend is not supported, and even just providing such a feature for experimentation is under debate. However, passing fine-grained fastmath related attributes on individual operations is generally accepted. This CL introduces an option to instruct the vector-to-llvm lowering phase to annotate floating-point reductions with the "reassociate" fastmath attribute, which allows the LLVM backend to use SIMD implementations for such constructs. Oher lowering passes can start using this mechanism right away in cases where reassociation is allowed.
Benefit: For some microbenchmarks on x86-avx2, speedups over 20 were observed for longer vector (due to cleaner, spill-free and SIMD exploiting code).
Usage: mlir-opt --convert-vector-to-llvm="reassociate-fp-reductions"
Reviewed By: ftynse, mehdi_amini
Differential Revision: https://reviews.llvm.org/D82624
show more ...
|
#
8d67d187 |
| 18-Jun-2020 |
River Riddle <riddleriver@gmail.com> |
[mlir][DialectConversion] Refactor how block argument types get converted
This revision removes the TypeConverter parameter passed to the apply* methods, and instead moves the responsibility of regi
[mlir][DialectConversion] Refactor how block argument types get converted
This revision removes the TypeConverter parameter passed to the apply* methods, and instead moves the responsibility of region type conversion to patterns. The types of a region can be converted using the 'convertRegionTypes' method, which acts similarly to the existing 'applySignatureConversion'. This method ensures that all blocks within, and including those moved into, a region will have the block argument types converted using the provided converter.
This has the benefit of making more of the legalization logic controlled by patterns, instead of being handled explicitly by the driver. It also opens up the possibility to support multiple type conversions at some point in the future.
This revision also adds a new utility class `FailureOr<T>` that provides a LogicalResult friendly facility for returning a failure or a valid result value.
Differential Revision: https://reviews.llvm.org/D81681
show more ...
|
#
c9eeeb38 |
| 18-Jun-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] remove print_i1 from runtime support library
Summary: The "i1" (viz. bool) type does not have a proper equivalent on the "C" size. So, to avoid any ABIs issues, we simply use prin
[mlir] [VectorOps] remove print_i1 from runtime support library
Summary: The "i1" (viz. bool) type does not have a proper equivalent on the "C" size. So, to avoid any ABIs issues, we simply use print_i32 on an i32 value of one or zero for true and false. This has the added advantage that one less function needs to be implemented when porting the runtime support library.
Reviewers: ftynse, bkramer, nicolasvasilache
Reviewed By: ftynse
Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, msifontes
Tags: #mlir
Differential Revision: https://reviews.llvm.org/D82048
show more ...
|
#
2d2c73c5 |
| 15-Jun-2020 |
Jacques Pienaar <jpienaar@google.com> |
[mlir] Remove OperandAdaptor
Use ::Adaptor alias instead uniformly. Makes the naming more consistent as adaptor can refer to attributes now too.
Differential Revision: https://reviews.llvm.org/D817
[mlir] Remove OperandAdaptor
Use ::Adaptor alias instead uniformly. Makes the naming more consistent as adaptor can refer to attributes now too.
Differential Revision: https://reviews.llvm.org/D81789
show more ...
|
#
5f9e0466 |
| 28-May-2020 |
Nicolas Vasilache <ntv@google.com> |
[mlir][Vector] Fix vector.transfer alignment calculation
https://reviews.llvm.org/D79246 introduces alignment propagation for vector transfer operations. Unfortunately, the alignment calculation is
[mlir][Vector] Fix vector.transfer alignment calculation
https://reviews.llvm.org/D79246 introduces alignment propagation for vector transfer operations. Unfortunately, the alignment calculation is incorrect and can result in crashes.
This revision fixes the calculation by using the natural alignment of the memref elemental type, instead of the resulting vector type.
If more alignment is desired, it can be done in 2 ways: 1. use a proper vector.type_cast to transform a memref<axbxcxdxf32> into a memref<axbxvector<cxdxf32>> giving a natural alignment of vector<cxdxf32> 2. add an alignment attribute to vector transfer operations and propagate it.
With this change the alignment in the relevant tests goes down from 128 to 4.
Lastly, a few minor cleanups are performed and the custom `isMinorIdentityMap` is deprecated.
Differential Revision: https://reviews.llvm.org/D80734
show more ...
|
#
c295a65d |
| 27-May-2020 |
aartbik <ajcbik@google.com> |
[mlir] [VectorOps] Add 'vector.flat_transpose' operation
Summary: Provides a representation of the linearized LLVM instrinsic. With tests and lowering implementation to LLVM IR dialect. Prepares bet
[mlir] [VectorOps] Add 'vector.flat_transpose' operation
Summary: Provides a representation of the linearized LLVM instrinsic. With tests and lowering implementation to LLVM IR dialect. Prepares better lowering for 2-D vector.transpose.
Reviewers: nicolasvasilache, ftynse, reidtatge, bkramer, dcaballe
Reviewed By: ftynse, dcaballe
Subscribers: mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D80419
show more ...
|