| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][acc] Add ACCImplicitData pass for implicit data attributes (#166472) This change adds the ACCImplicitData pass which implements the OpenACC specification for "Variables with Implicitly Determined Data Attributes" (OpenACC 3.4 spec, section 2.6.2). The pass automatically generates data clause operations (copyin, copyout, present, firstprivate, etc.) for variables used within OpenACC compute constructs (parallel, kernels, serial) that do not already have explicit data clauses. Key features: - Respects default(none) and default(present) clauses - Handles scalar vs. aggregate variables with different semantics: * Aggregates: present clause (if default(present)) or copy clause * Scalars: copy clause (kernels) or firstprivate (parallel/serial) - Generates privatization recipes when needed for firstprivate clauses - Performs alias analysis to avoid redundant data mappings - Ensures proper data clause ordering for partial entity access - Generates exit operations (copyout, delete) to match entry operations Requirements: - Types must implement acc::MappableType and/or acc::PointerLikeType interfaces to be considered candidates. - Operations accessing partial entities or creating subviews should implement acc::PartialEntityAccess and/or mlir::ViewLikeOpInterface for proper clause ordering. - Optionally pre-register acc::OpenACCSupport and mlir::AliasAnalysis if custom alias analysis, variable name determination, or error reporting is needed. | 8 个月前 | |
[mlir][acc] Adds attr to acc.present to identify default clause origin (#169114) The acc.present Op as generated by ACCImplicitData does not provide a way to differentiate between acc.present ops that are generated implicitly and the ones that are generated as result of an explicit default(present) clause in the source code. This differentiation would allow for better communication to the user on the decisions made by the compiler while managing data automatically between the host and the device. This commit adds this information as a discardable attribute on the acc.present op. | 8 个月前 | |
[mlir][acc] Erase empty kernel_environment ops during canonicalization (#166633) This change removes empty acc.kernel_environment operations during canonicalization. This could happen when the acc compute construct inside the acc.kernel_environment is optimized away in cases such as when only private variables are being written to in the loop. In cases of empty acc.kernel_environment ops with waitOperands, we still remove the empty acc.kernel_environment, but also create an acc.wait operation to take those wait operands to preserve synchronization behavior. | 8 个月前 | |
[mlir][OpenACC] add unstructured attributes for acc.loop with early exits (#164990) "!$acc loop" directive may be placed above loops with early exits. Currently flang lowers loop with early exits to explicit control flow (this may be revisited when MLIR allows early exits in structured region). The acc loop directive cannot simply be ignored in such case in lowering because it may hold data clauses that should be applied when reaching that point. This patch adds an "unstructured" attribute to acc.loop to support that case. An acc.loop with such attributes may hold data operands but must have no controls. It is expected that the loop logic is implemented in its body in a way that the acc dialect may not understand. Such acc.loop is just a container and the loop with early exit will be executed sequentially. | 8 个月前 | |
[acc] acc.loop verifier now requires parallelism determination flag (#143720) The OpenACC specification for acc loop describe that a loop's parallelism determination mode is either auto, independent, or seq. The rules are as follows. - As per OpenACC 3.3 standard section 2.9.6 independent clause: A loop construct with no auto or seq clause is treated as if it has the independent clause when it is an orphaned loop construct or its parent compute construct is a parallel construct. - As per OpenACC 3.3 standard section 2.9.7 auto clause: When the parent compute construct is a kernels construct, a loop construct with no independent or seq clause is treated as if it has the auto clause. - Additionally, loops marked with gang, worker, or vector are not guaranteed to be parallel. Specifically noted in 2.9.7 auto clause: If not, or if it is unable to make a determination, it must treat the auto clause as if it is a seq clause, and it must ignore any gang, worker, or vector clauses on the loop construct. The verifier for acc.loop was updated to enforce this marking because the context in which a loop appears is not trivially determined once IR transformations begin. For example, orphaned loops are implicitly independent, but after inlining into an acc.kernels region they would be implicitly considered auto. Thus now the verifier requires that a frontend specifically generates acc dialect with this marking since it knows the context. | 1 年前 | |
[MLIR] Fix FileCheck annotations and add 32-bit coverage (#167149) Addresses #93154 by ensuring the test RUN/FILECHECK prefixes across mlir/test/Conversion/FuncToLLVM/ and related files match their expected outputs, and adds an index-bitwidth=32 variant of expand-then-convert-to-llvm.mlir that exercises @collapse_shape_dynamic_with_non_identity_layout through the same MemRef-to-LLVM pipeline so the 32-bit layout descriptors are verified. | 8 个月前 | |
[mlir][acc] Ensure genAllocate uses provided variable name (#163861) The genAllocate API was documented to have the varName argument as optional. However, when it is provided, it becomes unexpected if the implementation does not use it. Since not all dialects have a way to store variable names, add one in the acc dialect and use it to store names of memref variables. This updates the API documentation, implementation of genAllocate for memref, and IR testing. | 9 个月前 | |
[mlir][acc] Extend PointerLikeType to provide alloc, dealloc, copy (#162328) A variable in an acc data clause operation must have a type that implements either PointerLikeType or a MappableType interface. These interfaces provide the contract that allows acc dialect and its transform passes to interact with a source dialect. One of these requirements is ability to generate code that creates memory for a private copy and ability to initialize that copy from another variable. Thus, update the PointerLikeType API to provide the means to create allocation, deallocation, and copy. This will be used as a way to fill in privatization and firstprivatization recipes. This new API was implemented for memref along with testing to exercise it via the implementation of a testing pass. | 9 个月前 | |
[mlir][acc] Extend PointerLikeType to provide alloc, dealloc, copy (#162328) A variable in an acc data clause operation must have a type that implements either PointerLikeType or a MappableType interface. These interfaces provide the contract that allows acc dialect and its transform passes to interact with a source dialect. One of these requirements is ability to generate code that creates memory for a private copy and ability to initialize that copy from another variable. Thus, update the PointerLikeType API to provide the means to create allocation, deallocation, and copy. This will be used as a way to fill in privatization and firstprivatization recipes. This new API was implemented for memref along with testing to exercise it via the implementation of a testing pass. | 9 个月前 | |
[mlir][acc] Ensure genAllocate uses provided variable name (#163861) The genAllocate API was documented to have the varName argument as optional. However, when it is provided, it becomes unexpected if the implementation does not use it. Since not all dialects have a way to store variable names, add one in the acc dialect and use it to store names of memref variables. This updates the API documentation, implementation of genAllocate for memref, and IR testing. | 9 个月前 | |
[mlir][acc] Ensure genAllocate uses provided variable name (#163861) The genAllocate API was documented to have the varName argument as optional. However, when it is provided, it becomes unexpected if the implementation does not use it. Since not all dialects have a way to store variable names, add one in the acc dialect and use it to store names of memref variables. This updates the API documentation, implementation of genAllocate for memref, and IR testing. | 9 个月前 | |
[acc] Expand OpenACCSupport to provide getRecipeName and emitNYI (#165628) Extends OpenACCSupport utilities to include recipe name generation and error reporting for unsupported features, providing foundation for variable privatization handling. Changes: - Add RecipeKind enum (private, firstprivate, reduction) for APIs that request a specific kind of recipe - Add getRecipeName() API to OpenACCSupport and OpenACCUtils that generates recipe names from types (e.g., "privatization_memref_5x10xf32_") - Add emitNYI() API to OpenACCSupport for graceful handling of not-yet-implemented cases - Generalize MemRefPointerLikeModel template to support UnrankedMemRefType - Add unit tests and integration tests for new APIs | 9 个月前 | |
[acc] Expand OpenACCSupport to provide getRecipeName and emitNYI (#165628) Extends OpenACCSupport utilities to include recipe name generation and error reporting for unsupported features, providing foundation for variable privatization handling. Changes: - Add RecipeKind enum (private, firstprivate, reduction) for APIs that request a specific kind of recipe - Add getRecipeName() API to OpenACCSupport and OpenACCUtils that generates recipe names from types (e.g., "privatization_memref_5x10xf32_") - Add emitNYI() API to OpenACCSupport for graceful handling of not-yet-implemented cases - Generalize MemRefPointerLikeModel template to support UnrankedMemRefType - Add unit tests and integration tests for new APIs | 9 个月前 | |
[mlir][acc] Add OpenACCSupport for extensible dialect handling (#164510) The OpenACC dialect must coexist with source language dialects (FIR, CIR, etc.) to enable offloading. While type interfaces ( PointerLikeType and MappableType) provide the primary contract for variable mapping, some scenarios require pipeline-specific customization or need to express information that cannot be adequately captured through operation and type interfaces alone. This commit introduces the OpenACCSupport analysis, which provides extensible support APIs that can be customized per-pipeline. The analysis follows the Concept-Model pattern used in MLIR's AliasAnalysis and is never invalidated, persisting throughout the pass pipeline. The initial API, getVariableName(Value) -> string, retrieves variable names from MLIR values by: - Checking for acc.var_name attributes - Extracting names from ACC data clause operations (e.g., acc.copyin) - Walking through ViewLikeOpInterface operations to find the source This will be used in the implicit data mapping pass to automatically generate device mappings with correct user-visible variable names. Usage: Passes call getAnalysis<OpenACCSupport>() to get a cached instance with either the default or a previously- registered custom implementation. Custom implementations can be registered in a setup pass by calling setImplementation() before the consumer pass runs. | 9 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 | ||
| 9 个月前 |