llvm-project/mlir/lib/Conversion/CMakeLists.txt

add_subdirectory(LoopsToGPU)
add_subdirectory(ControlFlowToCFG)
add_subdirectory(GPUToCUDA)
add_subdirectory(GPUToNVVM)
add_subdirectory(GPUToSPIRV)
add_subdirectory(StandardToLLVM)
add_subdirectory(StandardToSPIRV)
add_subdirectory(VectorToLLVM)
Extend AffineToGPU to support Linalg loops Extend the utility that converts affine loop nests to support other types of loops by abstracting away common behavior through templates. This also slightly simplifies the existing Affine to GPU conversion by always passing in the loop step as an additional kernel argument even though it is a known constant. If it is used, it will be propagated into the loop body by the existing canonicalization pattern and can be further constant-folded, otherwise it will be dropped by canonicalization. This prepares for the common loop abstraction that will be used for converting to GPU kernels, which is conceptually close to Linalg loops, while maintaining the existing conversion operational. PiperOrigin-RevId: 257172216 2019-07-09 20:26:18 +08:00			`add_subdirectory(LoopsToGPU)`
Lower affine control flow to std control flow to LLVM dialect This CL splits the lowering of affine to LLVM into 2 parts: 1. affine -> std 2. std -> LLVM The conversions mostly consists of splitting concerns between the affine and non-affine worlds from existing conversions. Short-circuiting of affine `if` conditions was never tested or exercised and is removed in the process, it can be reintroduced later if needed. LoopParametricTiling.cpp is updated to reflect the newly added ForOp::build. PiperOrigin-RevId: 257794436 2019-07-12 21:48:45 +08:00			`add_subdirectory(ControlFlowToCFG)`
Add a pass that translates a CUDA kernel function (tagged with nvvm.kernel) to a CUBIN blob for execution on CUDA GPUs. This is a first in a series of patches to build a simple CUDA runner to allow experimenting with MLIR code on GPUs. PiperOrigin-RevId: 253758915 2019-06-18 18:26:31 +08:00			`add_subdirectory(GPUToCUDA)`
Add lowering pass from GPU dialect operations to LLVM/NVVM intrinsics. PiperOrigin-RevId: 253551452 2019-06-17 18:56:20 +08:00			`add_subdirectory(GPUToNVVM)`
Initial implementation to translate kernel fn in GPU Dialect to SPIR-V Dialect This CL adds an initial implementation for translation of kernel function in GPU Dialect (used with a gpu.launch_kernel) op to a spv.Module. The original function is translated into an entry function. Most of the heavy lifting is done by adding TypeConversion and other utility functions/classes that provide most of the functionality to translate from Standard Dialect to SPIR-V Dialect. These are intended to be reusable in implementation of different dialect conversion pipelines. Note : Some of the files for have been renamed to be consistent with the norm used by the other Conversion frameworks. PiperOrigin-RevId: 260759165 2019-07-31 02:29:48 +08:00			`add_subdirectory(GPUToSPIRV)`
Start moving conversions to {lib,include/mlir}/Conversion Conversions from dialect A to dialect B depend on both A and B. Therefore, it is reasonable for them to live in a separate library that depends on both DialectA and DialectB library, and does not forces dependees of DialectA or DialectB to also link in the conversion. Create the directory layout for the conversions and move the Standard to LLVM dialect conversion as the first example. PiperOrigin-RevId: 253312252 2019-06-15 06:54:21 +08:00			`add_subdirectory(StandardToLLVM)`
NFC: Move Standard to SPIR-V conversion to lib/Conversion PiperOrigin-RevId: 256271759 2019-07-03 08:22:21 +08:00			`add_subdirectory(StandardToSPIRV)`
Add lowering of vector dialect to LLVM dialect. This CL is step 3/n towards building a simple, programmable and portable vector abstraction in MLIR that can go all the way down to generating assembly vector code via LLVM's opt and llc tools. This CL adds support for converting MLIR n-D vector types to (n-1)-D arrays of 1-D LLVM vectors and a conversion VectorToLLVM that lowers the `vector.extractelement` and `vector.outerproduct` instructions to the proper mix of `llvm.vectorshuffle`, `llvm.extractelement` and `llvm.mulf`. This has been independently verified to produce proper avx2 code. Input: ``` func @vec_1d(%arg0: vector<4xf32>, %arg1: vector<8xf32>) -> vector<8xf32> { %2 = vector.outerproduct %arg0, %arg1 : vector<4xf32>, vector<8xf32> %3 = vector.extractelement %2[0 : i32]: vector<4x8xf32> return %3 : vector<8xf32> } ``` Command: ``` mlir-opt vector-to-llvm.mlir -vector-lower-to-llvm-dialect --disable-pass-threading \| mlir-opt -lower-to-cfg -lower-to-llvm \| mlir-translate --mlir-to-llvmir \| opt -O3 \| llc -O3 -march=x86-64 -mcpu=haswell -mattr=fma,avx2 ``` Output: ``` vec_1d: # @vec_1d # %bb.0: vbroadcastss %xmm0, %ymm0 vmulps %ymm1, %ymm0, %ymm0 retq ``` PiperOrigin-RevId: 262895929 2019-08-12 19:08:26 +08:00			`add_subdirectory(VectorToLLVM)`