| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][LLVMIR] Fix identified structs with same name Different identified struct types may have the same name (""). Previously, these were deduplicated based on their name, which caused an assertion failure when nesting identified structs: %0 = type { %1 } %1 = type { i8 } declare void @fn(%0) Reviewed By: gysit Differential Revision: https://reviews.llvm.org/D156531 | 2 年前 | |
[IR] Enable opaque pointers by default This enabled opaque pointers by default in LLVM. The effect of this is twofold: * If IR that contains *neither* explicit ptr nor %T* types is passed to tools, we will now use opaque pointer mode, unless -opaque-pointers=0 has been explicitly passed. * Users of LLVM as a library will now default to opaque pointers. It is possible to opt-out by calling setOpaquePointers(false) on LLVMContext. A cmake option to toggle this default will not be provided. Frontends or other tools that want to (temporarily) keep using typed pointers should disable opaque pointers via LLVMContext. Differential Revision: https://reviews.llvm.org/D126689 | 4 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir][LLVMIR] Change ShuffleVectorOp to use assembly format This patch moves LLVM::ShuffleVectorOp to assembly format and in the process drops the extra type that can be inferred (both operand types are required to be the same) and switches to a dense integer array. The syntax change: // Before %0 = llvm.shufflevector %0, %1 [0 : i32, 0 : i32, 0 : i32, 0 : i32] : vector<4xf32>, vector<4xf32> // After %0 = llvm.shufflevector %0, %1 [0, 0, 0, 0] : vector<4xf32> Reviewed By: dcaballe Differential Revision: https://reviews.llvm.org/D132038 | 3 年前 | |
[AArch64][SME] Remove immediate argument restriction for svldr and svstr (#68565) The svldr_vnum and svstr_vnum builtins always modify the base register and tile slice and provide immediate offsets of zero, even when the offset provided to the builtin is an immediate. This patch optimises the output of the builtins when the offset is an immediate, to pass it directly to the instruction and to not need the base register and tile slice updates. Signed-off-by: chenmiao <15273704+chenmiao32@user.noreply.gitee.com> Signed-off-by: chenmiao <chenmiao32@huawei.com> | 1 年前 | |
[IR] Enable opaque pointers by default This enabled opaque pointers by default in LLVM. The effect of this is twofold: * If IR that contains *neither* explicit ptr nor %T* types is passed to tools, we will now use opaque pointer mode, unless -opaque-pointers=0 has been explicitly passed. * Users of LLVM as a library will now default to opaque pointers. It is possible to opt-out by calling setOpaquePointers(false) on LLVMContext. A cmake option to toggle this default will not be provided. Frontends or other tools that want to (temporarily) keep using typed pointers should disable opaque pointers via LLVMContext. Differential Revision: https://reviews.llvm.org/D126689 | 4 年前 | |
[mlir][llvm] Add comdat attribute to functions This revision adds comdat support to functions. Additionally, it ensures only comdats that have uses are imported/exported and only non-empty global comdat operations are created. Reviewed By: Dinistro Differential Revision: https://reviews.llvm.org/D153739 | 2 年前 | |
[mlir] Add stack alignment to the data layout dialect. The revision adds the stack alignment to the data layout dialect and it extends the LLVM dialect import and export to support the new data layout entry. One possible use case for the flag is the LLVM dialect inliner. The LLVM inliner queries the flag to determine if it is safe to update the alignment of an existing alloca. We may want to perform the same optimization inside of MLIR. Reviewed By: Dinistro Differential Revision: https://reviews.llvm.org/D147332 | 3 年前 | |
[mlir-translate] Support parsing operations other than 'builtin.module' as top-level This adds a '--no-implicit-module' option, which disables the insertion of a top-level 'builtin.module' during parsing. The translation APIs are also updated to take/return 'Operation*' instead of 'ModuleOp', to allow other operation types to be used. To simplify translations which are restricted to specific operation types, 'TranslateFromMLIRRegistration' has an overload which performs the necessary cast and error checking. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134237 | 3 年前 | |
[mlir][LLVM] Export DICompositeType as distinct MD when necessary This commit ensures that DICompositeTypes are exported as distinct metadata nodes for structures, classes, unions, and enumerations. Not emitting these as distinct metadata can potentially cause linking issues involving debug sections. Reviewed By: gysit Differential Revision: https://reviews.llvm.org/D154712 | 2 年前 | |
[Backport][Intrinsics] llvm.memcpy.inline length no longer needs to be constant Reference: https://github.com/llvm/llvm-project/commit/fdf94e1 Originally By: Alex Bradbury <asb@igalia.com> A test change was missing for mlir/test/Target/LLVMIR/llvmir-intrinsics.mlir in the initial commit. | 5 个月前 | |
[mlir] Add support for LLVMIR comdat operation The LLVM comdat operation specifies how to deduplicate globals with the same key in two different object files. This is necessary on Windows where e.g. two object files with linkonce globals will not link unless a comdat for those globals is specified. It is also supported in the ELF format. Differential Revision: https://reviews.llvm.org/D150796 | 3 年前 | |
[mlir][llvm] Add LLVM TargetExtType Add support for the llvm::TargetExtType to the MLIR LLVM dialect. Target extension types were introduced to represent target-specific types, which are opaque to the compiler and optimizations. The patch also enforces some of the constraints defined for the target extension type in the LLVM language reference manual. Signed-off-by: Lukas Sommer <lukas.sommer@codeplay.com> Reviewed By: ftynse, gysit, Dinistro Differential Revision: https://reviews.llvm.org/D151446 | 3 年前 | |
[mlir][llvm] Fix export of 64-bit integer function attributes The allocsize attribute is weird because it packs two 32-bit values into a 64-bit value. It also turns out that the passthrough attribute exporter was using int, which is incorrectly handling 64-bit integers. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D156574 | 2 年前 | |
[mlir][LLVM] Convert access group metadata to using attributes instead of ops Using MLIR attributes instead of metadata has many advantages: * No indirection: Attributes can simply refer to each other seemlessly without having to use the indirection of SymbolRefAttr. This also gives us correctness by construction in a lot of places as well * Multithreading safe: The Attribute infrastructure gives us thread-safety for free. Creating operations and inserting them into a block is not thread-safe. This is a major use case for e.g. the inliner in MLIR which runs in parallel * Easier to create: There is no need for a builder or a metadata region This patch therefore does exactly that. It leverages the new distinct attributes to create distinct access groups in a deterministic and threadsafe manner. Differential Revision: https://reviews.llvm.org/D155285 | 2 年前 | |
[mlir][nvgpu] Implement nvgpu.device_async_copy by NVVMToLLVM Pass nvgpu.device_async_copy is lowered into cp.async PTX instruction. However, NVPTX backend does not support its all mode especially when zero padding is needed. Therefore, current MLIR implementation genereates inline assembly for that. This work simplifies PTX generation for nvgpu.device_async_copy, and implements it by NVVMToLLVM Pass. Depends on D154060 Reviewed By: nicolasvasilache, manishucsd Differential Revision: https://reviews.llvm.org/D154345 | 2 年前 | |
Finish renaming getOperandSegmentSizeAttr() from operand_segment_sizes to operandSegmentSizes This renaming started with the native ODS support for properties, this is completing it. A mass automated textual rename seems safe for most codebases. Drop also the ods prefix to keep the accessors the same as they were before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
Finish renaming getOperandSegmentSizeAttr() from operand_segment_sizes to operandSegmentSizes This renaming started with the native ODS support for properties, this is completing it. A mass automated textual rename seems safe for most codebases. Drop also the ods prefix to keep the accessors the same as they were before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
[Flang][OpenMP][MLIR] Filter emitted code depending on declare target and device This patch adds support for selecting which functions are lowered to LLVM IR from MLIR depending on declare target information and whether host or device code is being generated. The approach proposed by this patch is to perform the filtering in two stages: - An MLIR transformation pass, which is added to the Flang translation flow after the OMPEarlyOutliningPass. The functions that are kept are those that match the OpenMP processor (host or device) the compiler invocation is targeting, according to the presence of the -fopenmp-is-target-device compiler option and declare target information. All functions contaning an omp.target are also kept, regardless of the declare target information of the function, due to the need for keeping target regions visible for both host and device compilation. - A filtering step during translation to LLVM IR, which is peformed for those functions that were kept because of the presence of a target region inside. If the targeted OpenMP processor does not match the declare target information of the function, then it is removed from the LLVM IR after its contents have been processed and translated. Since they should only contain an omp.target operation which, in turn, should have been outlined into another LLVM IR function, the wrapper can be deleted at that point. Depends on D150328 and D150329. Differential Revision: https://reviews.llvm.org/D147641 | 2 年前 | |
Finish renaming getOperandSegmentSizeAttr() from operand_segment_sizes to operandSegmentSizes This renaming started with the native ODS support for properties, this is completing it. A mass automated textual rename seems safe for most codebases. Drop also the ods prefix to keep the accessors the same as they were before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
Finish renaming getOperandSegmentSizeAttr() from operand_segment_sizes to operandSegmentSizes This renaming started with the native ODS support for properties, this is completing it. A mass automated textual rename seems safe for most codebases. Drop also the ods prefix to keep the accessors the same as they were before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
[MLIR] Remove explicit -opaque-pointers flag from test (NFC) | 2 年前 | |
[mlir][openacc] Cleanup acc.data from old data clause operands Since the new data operand operations have been added in D148389 and adopted on acc.data in D149673, the old clause operands are no longer needed. The LegalizeDataOpForLLVMTranslation will become obsolete when all operations will be cleaned. For the time being only the appropriate part are being removed. processOperands will also receive some updates once all the operands will be coming from an acc data operand operation. Reviewed By: razvanlupusoru Differential Revision: https://reviews.llvm.org/D150155 | 3 年前 | |
[mlir][OpenMP] Fixed internal compiler error with atomic update operation verification Fixes https://github.com/llvm/llvm-project/issues/61089 by updating the verification followed like translation from OpenMP+LLVM MLIR dialect to LLVM IR. Reviewed By: kiranchandramohan Differential Revision: https://reviews.llvm.org/D153217 | 2 年前 | |
Finish renaming getOperandSegmentSizeAttr() from operand_segment_sizes to operandSegmentSizes This renaming started with the native ODS support for properties, this is completing it. A mass automated textual rename seems safe for most codebases. Drop also the ods prefix to keep the accessors the same as they were before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
[mlir][NFC] Remove trailing whitespaces from *.td and *.mlir files. This is generated by running sed --in-place 's/[[:space:]]\+$//' mlir/**/*.td sed --in-place 's/[[:space:]]\+$//' mlir/**/*.mlir Reviewed By: rriddle, dcaballe Differential Revision: https://reviews.llvm.org/D138866 | 3 年前 | |
[mlir][OpenMP] Add support for using Opaque Pointers in the OpenMP Dialect The current OpenMP implementation assumes the use of typed pointers (or rather typed pointer like types). Given the support for typed pointers in LLVM is now pending removal, the OpenMP Dialect should be able to support opaque pointers as well, given that any users of it must lower OpenMP through the LLVM Dialect. This patch fixes the above and adds support for using LLVM opaque pointers with the OpenMP dialect. This is implemented by making all related code not make use of the element type of pointer arguments. The few (one) op requiring a pointer element type now use an explicit TypeAttr for representing the element type. More concretely, the list of changes are: * omp.atomic.read now has an extra TypeAttr (also in syntax) which is the element type of the values read and stored from the operands * omp.reduction now has an type argument in the syntax for both the accmulator and operand since the operand type can no longer be inferred from the accumulator * OpenMPToLLVMIRTranslation.cpp was rewritten to never query element types of pointers * Adjusted the verifier to be able to handle pointers without element types Differential Revision: https://reviews.llvm.org/D143582 | 3 年前 | |
[mlir][OpenMP] Add support for using Opaque Pointers in the OpenMP Dialect The current OpenMP implementation assumes the use of typed pointers (or rather typed pointer like types). Given the support for typed pointers in LLVM is now pending removal, the OpenMP Dialect should be able to support opaque pointers as well, given that any users of it must lower OpenMP through the LLVM Dialect. This patch fixes the above and adds support for using LLVM opaque pointers with the OpenMP dialect. This is implemented by making all related code not make use of the element type of pointer arguments. The few (one) op requiring a pointer element type now use an explicit TypeAttr for representing the element type. More concretely, the list of changes are: * omp.atomic.read now has an extra TypeAttr (also in syntax) which is the element type of the values read and stored from the operands * omp.reduction now has an type argument in the syntax for both the accmulator and operand since the operand type can no longer be inferred from the accumulator * OpenMPToLLVMIRTranslation.cpp was rewritten to never query element types of pointers * Adjusted the verifier to be able to handle pointers without element types Differential Revision: https://reviews.llvm.org/D143582 | 3 年前 | |
[mlir][rocdl] Change the translation of GridDim*Op to __ockl_get_num_groups Currently, ROCDL::GridDim*Op is being translated to __ockl_get_global_size, however to match the meaning of gpu.grid_dim it should instead be translated to __ockl_get_num_groups. This change would also make it agree with the meaning of gridDimx.* in HIP, see: https://github.com/ROCm-Developer-Tools/hipamd/blob/develop/include/hip/amd_detail/amd_hip_runtime.h#L257 Difference between the functions: __ockl_get_global_size = blockDim * numBlocks __ockl_get_num_groups = numBlocks Reviewed By: krzysz00 Differential Revision: https://reviews.llvm.org/D156009 | 2 年前 | |
[mlir][llvm] Add LLVM TargetExtType Add support for the llvm::TargetExtType to the MLIR LLVM dialect. Target extension types were introduced to represent target-specific types, which are opaque to the compiler and optimizations. The patch also enforces some of the constraints defined for the target extension type in the LLVM language reference manual. Signed-off-by: Lukas Sommer <lukas.sommer@codeplay.com> Reviewed By: ftynse, gysit, Dinistro Differential Revision: https://reviews.llvm.org/D151446 | 3 年前 | |
[mlir][flang] Convert TBAA metadata to an attribute representation The current representation of TBAA is the very last in-tree user of the llvm.metadata operation. Using ops to model metadata has a few disadvantages: * Building a graph has to be done through some weakly typed indirection mechanism such as SymbolRefAttr * Creating the metadata has to be done through a builder within a metadata op. * It is not multithreading safe as operation insertion into the same block is not thread-safe This patch therefore converts TBAA metadata into an attribute representation, in a similar manner as it has been done for alias groups and access groups in previous patches. This additionally has the large benefit of giving us more "correctness by construction" as it makes things like cycles in a TBAA graph, or references to an incorrectly typed metadata node impossible. Differential Revision: https://reviews.llvm.org/D155444 | 2 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir] X86Vector: Add AVX Rsqrt Reviewed By: aartbik Differential Revision: https://reviews.llvm.org/D99818 | 5 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 5 个月前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 5 年前 |